ProFTPD mini-HOWTO - Configuring a <Directory>

## Configuring a `<Directory>`

Use of the `<Directory>` configuration directive is, in general, straightforward. However, there are a few caveats of which to be aware.

First, it is not necessary to nest `<Directory>`; the daemon will not let one do this, in fact. The daemon will determine automatically the relations of `<Directory>` paths, depending on the path given and surrounding configuration context.

Always use the normal, absolute path for a `<Directory>` section, regardless of whether that directory will eventually be accessed during a session which has been `chroot`'d, as for `<Anonymous>` or `DefaultRoot`ed sessions. There are two allowed exceptions to the rule of using absolute paths: if the path has a `~` prefix, or if the `<Directory>` occurs within a `<Anonymous>` section. In the latter case, the path may be relative (i.e. does not need to start with a `/`), in which case the path will be relative to the directory to which anonymous sessions are restricted.

If the name of the directory contains spaces, you should enclose the entire directory name in quotations, e.g.:

      <Directory "/path/to/My Directory">

As noted in the documentation, use of a `/*` suffix on a path will change the effect of a `<Directory>` section slightly. For example:

      <Directory /path/to/dir>

applies the section's configuration directives to the `dir` directory and its contents, while:

      <Directory /path/to/dir/*>

applies the section's configuration directives only to the contents of `dir`, not to the directory itself. This is a small distinction, but it can often cause misconfigurations. In general, unless you know what you're doing, it's best not to use a `/*` suffix.

Also, a `*` within a path, such as:

      <Directory /path/to/*/dir>

will only match that single directory level, and will not match multiple directory levels. This means that the above `<Directory>` will match:

      /path/to/a/dir
      /path/to/b/dir

because `*` will match the `a/` and `b/`, as they are on the same level in the path as `*`. However, the following paths will not match:

      /path/to/some/other/dir
      /path/to/some/other/level/dir

since `*` does not expand to `some/other/` or `/some/other/level/`; they cover multiple levels.

There is another case about which the administrator should know: for the purposes of handling the `APPE`, `RETR`, `STOR`, and `STOU` FTP commands, the daemon will match a `<Directory>` path with the filename appended. As above, in most cases this will not matter much. However, consider the case where the administrator specifically wants to use the trailing `/*`, as when she wants a particular `<Limit>` to apply to all subdirectories of a given directory, but not to that directory itself. For example, the administrators wishes to block anonymous uploads everywhere except for subdirectories of `upload/`:

      <Anonymous ~ftp>
        User ftp
        Group ftp

        UserAlias anonymous ftp

        <Limit WRITE>
          DenyAll
        </Limit>

        <Directory upload/*>
          <Limit STOR>
            AllowAll
          </Limit>
        </Directory>
      </Anonymous>

This configuration looks like it should work, allowing files to be uploaded only to subdirectories of `upload/`, but not to the `upload/` directory itself. As described above, though, the daemon will append the filename being uploaded via `STOR` to the path used when looking up `<Directory>`, meaning that `upload/filename` will match `upload/*`, and allow files to be uploaded into `upload/`. In this particular case, then, what is wanted is to use this `<Directory>` pattern:

        <Directory upload/*/*>
          <Limit STOR>
            AllowAll
          </Limit>
        </Directory>

which will achieve the desired effect of allowing uploads only in subdirectories of the given directory, `upload/`.

Also, it is good to keep in mind the similarity between a `<Directory>` section and a `.ftpaccess` file. In some cases, using `.ftpaccess` files might be more convenient. The `AllowOverride` configuration directive (which first appeared in the 1.2.7rc1 release) will provide fine-grained control over when `.ftpaccess` files will be honored.

Last Updated: $Date: 2004/10/17 23:42:28 $