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.

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/05/29 04:22:59 $