Re: deny deleting a file for users
From: Brian Hatch (focus-linux_at_ifokr.org)
Date: Tue, 3 Jun 2003 11:59:28 -0700 To: Godwin Stewart <firstname.lastname@example.org>
> > ... "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
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",
-- Brian Hatch # rm -rf /bin/laden Systems and Security Engineer http://www.ifokr.org/bri/ Every message PGP signed
- application/pgp-signature attachment: stored