> > ... "removing parts of this file or append text" is in opposition to 'not > > being able to delete a file'. because, they all require 'write' > > permission. > > Actually, one can exist without the other. > > If user A has write permissions on the DIRECTORY containing file B, but not > on the file itself, then the user can DELETE the file but not modify it. > > OTOH, if user A does NOT have write permission to the directory, then they > CANNOT delete (nor create) files in the directory. All you have to do is > make sure there is a null-length file already in the directory, and the user > will be able to read/write it (provided it has the right permissions) but > NOT delete it.
Creating/renaming/deleting files requires directory write+execute access. This makes sense: what are you editing? The directory. You're not changing the file, you're changing the directory entry that points to it. If you have write+execute to a dir, you can delete anyone's files, regardless of their file perms. You can create files in the dir or rename them. If the dir has the sticky bit set (chmod +t dirname) then you can only delete or rename files that belong to you, you cannot delete or rename other people's files. Now the problem with the original situation was that the files were in the user's home directory. In general, you own your own home directory. If a directory has the sticky bit set (would dissalow you to remove other's files) or doesn't have the write+execute bit set (would dissalow you creating/renaming/deleting any files) then normally you'd be fine. But if they own the dir, they can always reset the permissions on it to get around it. For a quick "Are you sure you understand file perms in Unix", see http://www.hackinglinuxexposed.com/articles/20030417.html -- Brian Hatch # rm -rf /bin/laden Systems and Security Engineer http://www.ifokr.org/bri/ Every message PGP signed
pgp00000.pgp
Description: PGP signature
