This is a discussion on Re: [Proftpd-user] Limit, Limit WRITE, - proftpd ; > Thus I was surprised upon moving on to the next testing that the > WRITE command group used with Limit includes only RNTO. In my > testing I verified that both RNFR and RNTO were required, as rename > ...
> Thus I was surprised upon moving on to the next testing that the
> WRITE command group used with Limit includes only RNTO. In my
> testing I verified that both RNFR and RNTO were required, as rename
> can be used to move a subdirectory out _from_ a directory, simulating
> the effect of rmdir.
The specific reason for this, I believe, is that to effect a rename, an
FTP client must send RNFR, followed by RNTO. The actual renaming of the
file/directory occurs during the handling of RNTO (in proftpd, anyway),
hence why RNTO is in the WRITE group. The handling of RNFR does little
more than set up the state within the session information.
That said, I can't see why adding RNFR to the WRITE group would be a bad
thing; it would return an error to the FTP client earlier, if that
command was limited. Care to open a request for this on bugs.proftpd.org?
> Also I'd like to note the perhaps less obvious point that restricting
> MKD/XMKD/RMD/XRMD has absolutely no effect on directory renaming,
> even though a rename may have the same effect. How could that be
> mentioned in the documentation? (without confusion, that is)
I'll add this note to the FAQ section of the Limit documentation.
> the restricted directory. That is, even if RNTO was restricted, you
> could rename into the restricted directory from the home
> directory. How should that be described, as bug or misunderstood feature?
There's a longstanding issue with regard to .ftpaccess files, and how any
configurations in them are enforced. It is related to how proftpd
processes any directory-related command, absolute versus relative paths,
etc. In general, for now, unless you must, I'd recommend not using
..ftpaccess files. It's something I'm hoping to address in the 1.3.2
release cycle; fixing this issue involves touching the proftpd core code
which looks up configuration directives, and thus is quite likely to break
For it is only the finite that has wrought and suffered; the infinite lies
stretched in smiling repose.
-Ralph Waldo Emerson
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
ProFTPD Users List