Path: utzoo!utgpu!watmath!clyde!bellcore!texbell!killer!ames!pacbell!sactoh0!tree!stever
From: stever@tree.UUCP (Steve Rudek)
Newsgroups: comp.unix.wizards
Subject: Re: Nasty Security Hole?
Summary: read, write, execute modes -- we need a 4th: append
Keywords: mail permissions security
Message-ID: <145@tree.UUCP>
Date: 18 Nov 88 21:38:56 GMT
References: <175@ernie.NECAM.COM> <189@wyn386.UUCP> <31681@think.UUCP>
Distribution: na
Organization: TREE BBS (916)-349-0385 Sacramento, Ca
Lines: 27

In article <31681@think.UUCP>, barmar@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?