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 DefaultRooted 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 will appear in the 1.2.7rc1 release) will provide fine-grained control over when .ftpaccess files will be honored.


Last Updated: $Date: 2004/04/10 18:44:30 $