<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/dirbecause
* 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/dirsince
* 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.