Hello, am I complete stupid or is there a serious problem with 8.1-RELEASE: I can write files which I have no write access to, if I have write access to the directory of the file. How to reproduce (tested with UFS2): mkdir /tmp/testdir touch /tmp/testdir/testfile chown -R nobody:intern /tmp/testdir chmod 751 /tmp/testdir chmod 640 /tmp/testdir/testfile ls -ld /tmp/testdir drwxr-x--x 2 nobody intern 512 25 Okt 23:03 /tmp/testdir ls -l /tmp/testdir total 0 -rw-r----- 1 nobody intern 0 25 Okt 23:03 testfile exit id uid=9001(harry) gid=9001(harry) groups=9001(harry),0(wheel),5(operator),68(dialer),919(vboxusers),5090(intern).... -> Fine so far, editing testfile doesn't work chmod g+w testdir/ (as superuser, exit again) ls -ld testdir drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir ls -l testdir total 0 -rw-r----- 1 nobody intern 0 25 Okt 23:03 testfile -> Now editing with vi (as user harry) changes the ownership of the file and writing is successfull: ls -l testdir/ total 2 -rw-r----- 1 harry intern 5 25 Okt 23:10 testfile This means file permission mode is irrelevant if the user has write access to the directory of the file. I can hardly believe that this is intentional. Why does a write lead to owbership changes? How should I give users write access to directories but prohibit deliting particular files? Do I have to use uunlnk flag? Sorry for that basic question, but I must have been missing something in the last 10 years... Thanks in advance, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20101025/78382c12/signature.pgp
schrieb Harald Schmalzbauer am 25.10.2010 23:20 (localtime):> Hello, > > am I complete stupid or is there a serious problem with 8.1-RELEASE: > I can write files which I have no write access to, if I have write > access to the directory of the file....> This means file permission mode is irrelevant if the user has write > access to the directory of the file. I can hardly believe that this is > intentional. Why does a write lead to owbership changes? > How should I give users write access to directories but prohibit > deliting particular files? Do I have to use uunlnk flag? > Sorry for that basic question, but I must have been missing something in > the last 10 years...Sorry for the noise, digging through lots of not-deep-enough information I finally found: http://content.hccfl.edu/pollock/aunix1/filepermissions.htm Now I can remember that I already was upset about this, one decade ago, and there was a reason not to use the POSIX permission model at all for so long. In that particular case I'll have to use the uchg flag. Sorry again for the noise! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20101025/7f5df57a/signature.pgp
On Oct 25, 2010, at 2:20 PM, Harald Schmalzbauer wrote:> chmod g+w testdir/ (as superuser, exit again) > ls -ld testdir > drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir > ls -l testdir > total 0 > -rw-r----- 1 nobody intern 0 25 Okt 23:03 testfile > > -> Now editing with vi (as user harry) changes the ownership of the > file and writing is successfull: > ls -l testdir/ > total 2 > -rw-r----- 1 harry intern 5 25 Okt 23:10 testfile[ ... ]> Why does a write lead to owbership changes?You can't actually write to the file when owned by nobody as harry. However, since you have write permissions to the directory, you can delete the file and write a new file which is also called testfile. $ echo "hi" >> testfile cannot create testfile: Permission denied ...and in vi, force write ("w!") gives "Error: testfile: Permission denied." Perhaps you're using some odd tweaks to vi...?> How should I give users write access to directories but prohibit deliting particular files? Do I have to use uunlnk flag?No, you can set the sticky bit on the directory, which is what /tmp uses: STICKY DIRECTORIES A directory whose `sticky bit' is set becomes an append-only directory, or, more accurately, a directory in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files. Regards, -- -Chuck
On 10/25/2010 18:28, Chuck Swiger wrote:> chmod g+w testdir/ (as superuser, exit again) >> > > ls -ld testdir >> > > drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir >> ls -l testdir >> total 0 >> -rw-r----- 1 nobody intern 0 25 Okt 23:03 testfile > >> -> Now editing with vi (as user harry) changes the ownership of the >> file and writing is successfull: >> ls -l testdir/ >> total 2 >> -rw-r----- 1 harry intern 5 25 Okt 23:10 testfile > > A file in a sticky directory may only be removed or renamed > by a user if the user has write permission for the directory and the user > is the owner of the file, the owner of the directory, or the super-user.Obviously he is not the owner of the file, directory, nor the superuser in this case so if I am missing something here please forgive me but I still see a big problem with this.... -- jhell,v
On 10/29/2010 23:27, jhell wrote:> On 10/25/2010 18:28, Chuck Swiger wrote: >> chmod g+w testdir/ (as superuser, exit again) >>> >> >> ls -ld testdir >>> >> >> drwxrwx--x 2 nobody intern 512 25 Okt 23:03 testdir >>> ls -l testdir >>> total 0 >>> -rw-r----- 1 nobody intern 0 25 Okt 23:03 testfile >> >>> -> Now editing with vi (as user harry) changes the ownership of the >>> file and writing is successfull: >>> ls -l testdir/ >>> total 2 >>> -rw-r----- 1 harry intern 5 25 Okt 23:10 testfile >> >> A file in a sticky directory may only be removed or renamed >> by a user if the user has write permission for the directory and the user >> is the owner of the file, the owner of the directory, or the super-user. > > > Obviously he is not the owner of the file, directory, nor the superuser > in this case so if I am missing something here please forgive me but I > still see a big problem with this.... >Never mind... forhot the chmod g+w. -- jhell,v