--===============0550422296==
Content-Type: multipart/alternative;
boundary="=====================_286975390==.ALT"

--=====================_286975390==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

I'm trying to organize a set of 'normal' .ftpaccess setups. I'm
drawing on past requests from users/admins. One of these was "don't
let people mess up my directory structure!"

So in testing the scenarios that I could think of I've already
figured out it is insufficient simply to use

because using rename you can easily "mess up" things. So I've
decided that the minimum restrictions are

to get the desired behavior.

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.

So I believe the omission of RNFR from group WRITE is wrong. Does
that seem reasonable?

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)

Below is a summary of my testing of rename and directories. I tried
to make it readable (I'm sure I failed). I was testing against CVS
20070920 with -v identifying string 1.3.1rc4

For me the truly astonishing part below is that restricting either
one of RNFR and RNTO _alone_ had no effect on renames from outside
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?

The directory containing the .ftpaccess file is /upload/. We start
sessions in the home directory /.
homesubdir is /homesubdir/
uploadsubdir is /upload/uploadsubdir/


rename homesubdir upload/test
rename upload/test homesubdir
rename upload/uploadsubdir test
rename test upload/uploadsubdir
cd upload
rename uploadsubdir test fail
rename ../homesubdir test
rename test ../homesubdir fail
rename uploadsubdir ../test fail


rename homesubdir upload/test
rename upload/test homesubdir
rename upload/uploadsubdir test
rename test upload/uploadsubdir
cd upload
rename uploadsubdir test fail
rename ../homesubdir test fail
rename uploadsubdir ../test


rename homesubdir upload/test fail
rename upload/uploadsubdir test fail
cd upload
rename uploadsubdir test fail
rename ../homesubdir test fail
rename uploadsubdir ../test fail


--=====================_286975390==.ALT
Content-Type: text/html; charset="us-ascii"



I'm trying to organize a set of 'normal' .ftpaccess setups.  I'm
drawing on past requests from users/admins.  One of these was
"don't let people mess up my directory structure!"


So in testing the scenarios that I could think of I've already figured
out it is insufficient simply to use

    <Limit MKD XMKD RMD XRMD>

because using rename you can easily "mess up" things.  So
I've decided that the minimum restrictions are

    <Limit MKD XMKD RMD XRMD RNTO RNFR>

to get the desired behavior.


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.


So I believe the omission of RNFR from group WRITE is wrong.  Does
that seem reasonable?


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)


Below is a summary of my testing of rename and directories.  I tried
to make it readable (I'm sure I failed).   I was testing
against CVS 20070920 with -v identifying string 1.3.1rc4


For me the truly astonishing part below is that restricting either one of
RNFR and RNTO _alone_ had no effect on renames from outside 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?


The directory containing the .ftpaccess file is /upload/.  We start
sessions in the home directory /.

    homesubdir      is
/homesubdir/

    uploadsubdir    is
/upload/uploadsubdir/


  <Limit MKD XMKD RNFR>

    rename
homesubdir          
upload/test

    rename
upload/test         
homesubdir

    rename upload/uploadsubdir  test

    rename
test                
upload/uploadsubdir

    cd upload

    rename
uploadsubdir        
test                 
fail

    rename
.../homesubdir        test

    rename
test                
.../homesubdir         fail

    rename
uploadsubdir        
.../test              
fail


  <Limit MKD XMKD RNTO>

    rename
homesubdir          
upload/test

    rename
upload/test         
homesubdir

    rename upload/uploadsubdir  test

    rename
test                
upload/uploadsubdir

    cd upload

    rename
uploadsubdir        
test                 
fail

    rename
.../homesubdir       
test                 
fail

    rename
uploadsubdir        
.../test


  <Limit MKD XMKD RNTO RNFR>

    rename
homesubdir          
upload/test          
fail

    rename upload/uploadsubdir 
test                 
fail

    cd upload

    rename
uploadsubdir        
test                 
fail

    rename
.../homesubdir       
test                 
fail

    rename
uploadsubdir        
.../test              
fail





--=====================_286975390==.ALT--


--===============0550422296==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--===============0550422296==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html
--===============0550422296==--