From: TJ S. <cas...@us...> - 2010-01-05 17:00:30
|
Update of /cvsroot/pdd/www.proftpd.org/docs/howto In directory sfp-cvsdas-2.v30.ch3.sourceforge.com:/tmp/cvs-serv30606 Modified Files: Directory.html Log Message: Updating website copy of Directory howto. Index: Directory.html =================================================================== RCS file: /cvsroot/pdd/www.proftpd.org/docs/howto/Directory.html,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** Directory.html 17 Aug 2007 00:11:26 -0000 1.1 --- Directory.html 5 Jan 2010 17:00:21 -0000 1.2 *************** *** 19,26 **** <p> ! First, it is not necessary to nest <code><Directory></code>; the ! daemon will not let one do this, in fact. The daemon will determine ! automatically the relations of <code><Directory></code> paths, ! depending on the path given and surrounding configuration context. <p> --- 19,34 ---- <p> ! First, it is not necessary to nest <code><Directory></code> sections, ! like: ! <pre> ! <Directory /path/to/dir> ! <Directory /path/to/dir/subdir> ! ... ! </Directory> ! </Directory> ! </pre> ! The daemon will not let one do this, in fact. The daemon will determine ! automatically the relations of <code><Directory></code> paths, depending ! on the path given and surrounding configuration context. <p> *************** *** 44,47 **** --- 52,67 ---- <p> + Any configuration directives in a <code><Directory></code> section + will apply to that directory <i>and to all of the contents of that directory + recursively</i>. Thus if you use: + <pre> + <Directory /path/to/dir> + Umask 022 + </Directory> + </pre> + Then that <code>Umask</code> value will be used within the + "/path/to/dir/subdir/" directory as well. + + <p> As noted in the documentation, use of a <code>/*</code> suffix on a path will change the effect of a <code><Directory></code> section *************** *** 139,142 **** --- 159,317 ---- <p> + The fact that <code><Directory></code> sections can be used to + refer to specific <i>files</i>, in addition to directories, is not obvious. + However, there are some cases where it can be useful to use this feature. + One proftpd user used this feature in the following way: the + <code>DirFakeMode</code> was used to make all files look read-only (mostly + so that FTP mirroring tools would create a read-only mirror of the site). + However, a particular file on the site needed have execute permissions, + even in the FTP mirrored site. A <code><Directorygt;</code> section + was used just for this one file, <i>e.g.</i>: + <pre> + # Make all files look read-only to clients, regardless of the actual + # permissions on the filesystem + DirFakeMode 0444 + + <Anonymous /var/ftpd> + + # However, for this script, we need it to look like it is executable, too + <Directory /var/ftpd/bin/script> + DirFakeMode 0555 + </Directory> + + </Anonymous> + </pre> + + <p><a name="FAQ"></a> + <b>Frequently Asked Questions</b><br> + + <p><a name="MultipleDirectoriesSamePath"> + <font color=red>Question</font>: What happens if I configure two <code><Directory></code> sections for the exact same path?<br> + <font color=blue>Answer</font>: If you use explicit paths, then the config + parser will choke on the duplicate <code><Directory></code> sections. + For example, if you tried: + <pre> + <Directory /path/to/dir> + <Limit ALL> + DenyAll + </Limit> + </Directory> + + <Directory /path/to/dir> + <Limit ALL> + AllowAll + </Limit> + + <Limit WRITE> + DenyAll + </Limit> + </Directory> + </pre> + When starting <code>proftpd</code>, you would see something like: + <pre> + - Fatal: <Directory>: <Directory> section already configured for '/path/to/dir' on line 39 of '/etc/ftpd/proftpd.conf' + </pre> + + <p> + But what if you have the two <code><Directory></code> sections, but + one of the sections uses a wildcard character which would still match the + same path? For example: + <pre> + <Directory /path/to/dir> + <Limit ALL> + DenyAll + </Limit> + </Directory> + + <Directory /path/*/dir> + <Limit ALL> + AllowAll + </Limit> + + <Limit WRITE> + DenyAll + </Limit> + </Directory> + </pre> + This time, the config parser would not choke; <code>proftpd</code> would start + up normally. When it came time to look up the <code><Directory></code> + section to use, <i>e.g.</i> for uploading to "/path/to/dir/test.txt", + the matching <code><Directory></code> section <i>which appears later in + the config file</i> wins. In the above example, the upload to + "/path/to/dir/test.txt" would be denied (because the wildcard-using + <code><Directory></code> section appears later, and it has a + <code><Limit WRITE></code> section denying writes). + + <p> + However, if you simply reversed the order of the above + <code><Directory></code> sections and tried to upload to + "/path/to/subdir/test.txt", <i>e.g.</i>: + <pre> + <Directory /path/*/dir> + <Limit ALL> + AllowAll + </Limit> + + <Limit WRITE> + DenyAll + </Limit> + </Directory> + + <Directory /path/to/dir> + <Limit ALL> + DenyAll + </Limit> + </Directory> + </pre> + the upload would succeed, since the non-wildcard-using + <code><Directory></code> section appeared later in the config. + + <p><a name="PreventDirectoryRename"> + <font color=red>Question</font>: How can I prevent a specific directory from + being renamed? I am currently trying: + <pre> + <Directory /dir/*> + <Limit CWD XCWD RNFR RNTO> + AllowAll + </Limit> + + <Limit ALL> + DenyAll + </Limit> + </Directory> + + <Directory /dir/subdir> + <Limit WRITE> + DenyAll + </Limit> + </Directory> + </pre> + to keep "/dir/subdir" from being renamed, but it doesn't work!<br> + <font color=blue>Answer</font>: The trick is to block the <code>RNFR</code> + command within the <code><Directory></code> section for that + specific directory, <i>i.e.</i>: + <pre> + <Directory /dir/subdir> + <Limit RNFR WRITE> + DenyAll + </Limit> + </Directory> + </pre> + + <p> + The reason the original config did not work as expected is that + <code>proftpd</code>, when handling the <code>RNTO</code> command (<i>e.g.</i> "<code>RNTO subdir2</code>"), would <b>not</b> match the + <code><Directory /dir/subdir></code> section for the path "/dir/subdir2", + but instead matches the <code><Directory /dir/*></code> section. + + <p> + Renaming of files via FTP is done by first sending the <code>RNFR</code> + command (for the old filename), then sending <code>RNFTO</code> (with the + new filename). By placing <code>RNFR</code> in the + <code><Directory /dir/subdir></code> section's <code><Limit></code> + list, we make sure that the <code><i>RNFR</i></code> <i>does</i> match the + <code><Directory /dir/subdir></code> section, and is thus denied. + + <p> <hr> Last Updated: <i>$Date$</i><br> |