From: ghod@drycas.club.cc.cmu.edu Subject: Re: Security problem: SLS/99.4/extfs Date: 10 Feb 1993 18:40:47 -0500
In article <1993Feb7.040547.3058@cc.umontreal.ca>, duperval@ERE.UMontreal.CA (Duperval Laurent) writes:
> I noticed something bizarre today:
>
> Whenever a directory has 777 permision on it, anyone can remove any file in
> that directory. I know this is not proper behavior. Does anyone know the
> cure for it?
>
> --
> Laurent Duperval, B. Sc. | The opinions expressed herein are my own and
> | do not represent those of this establishment
> duperval@ere.umontreal.ca | That's because they don't have enough $$$
> duperval@jsp.umontreal.ca | to afford them. Noone does.
I beg to differ, but this is indeed proper behavior. The ability do delete
a file does not depend on the permissions of the file, but on those of the
directory in which the file resides. Deleting a file does not require
modifying the file; it requires modifying the directory. Same goes for
renaming files. Hence, if your directory is world-writeable and someone wants
to nuke one of your files, the file's permissions won't save you. (This is
not true of some OS's, like VMS (yech), where you actually have a 'delete'
bit in the permission mask. Also, systems with C2 level security support
access control lists in addition to file permissions which allow you to
specify exactly who can do what with which files, and when.)
Obviously, this causes problems where several users have access to a common
directory, such as /tmp. To change this behavior, you can set the sticky bit
on the directory (i.e. chmod 1777 /tmp). This will prevent users from
deleting files in /tmp that they don't own while still granting all users
permission to create new files as they need. This is most likely the 'cure'
you're looking for, but what you're describing isn't really a 'disease'.
Note that not all flavors of Unix support this feature (Coherent leaps to
mind), but Linux does and that's all that really matters. :)
-Bill