Nasty Security Hole?

[Steve Rudek]

In article <31681 at think.UUCP>, barmar at think.COM (Barry Margolin) writes:
> You probably think this is even worse, because you now think that
> anyone can remove any file.  That's not true, however.  Removing files
> is considered an operation on the DIRECTORY.  In order to remove a
> file, you must have write permission on the directory.

Yeah, unfortunately write permission to a file or directory is an
all-or-nothing matter.  You can't give permission to add a new file to
a directory without also granting permission to wipe out everything in
that directory, can you?

For example, I'd like to set up a directory for source code contributions
from our users.  Folks should be able to cp source in but not modify (or
erase!) other peoples contributions.  A fourth file access mode, enforced
by the kernel, would be nice: an "append" mode would allow people to add
files to a directory or add text to a file but NOT remove files from a
directory nor molest the existing contents of a file.  It occurs to me that
the setuid/setgid idea was a clever kludge.  Like many kludges it solved
obvious problems at the expense of creating more pernicious ones.

Much of the need for setuid (scripts, especially) would disappear
if a decent way existed to to protect the integrity of existing files in
a directory.  Perhaps the kernel should consult *both* the directory
permissions AND the specific file permissions before deciding on access
rights?  I haven't thought this through, but what if people (other than
the owner of the directory) needed write permission to BOTH the directory
AND the file in order to rm it?