Path: utzoo!attcan!uunet!husc6!rutgers!mailrus!cornell!uw-beaver!uw-june!ka
From: ka@june.cs.washington.edu (Kenneth Almquist)
Newsgroups: comp.unix.wizards
Subject: Re: Nasty Security Hole?
Keywords: mail permissions security
Message-ID: <6527@june.cs.washington.edu>
Date: 26 Nov 88 04:54:46 GMT
References: <175@ernie.NECAM.COM> <189@wyn386.UUCP> <2955@ingr.UUCP> <1031@alobar.ATT.COM>
Distribution: na
Organization: U of Washington, Computer Science, Seattle
Lines: 26

grs@alobar.ATT.COM (Gregg Siegfried) writes:
>                                      By setting the sticky bit (chmod 1xxx
> file) on a directory, users are prevented from removing any files from that
> directory except those that they own, even if the directory permissions are
> 777.

That means that I can create directory entries which I can't delete.  Yuck!
I would think that the rule, "You can delete anything that you create,"
would be a *minimum* sanity check for a security model.  I mean, if system
security really depends upon the existence of some object which I created,
then I could defeat system security by not creating the object in the
first place, rather than by deleting the object later.

I'm not sure what problem this "feature" is supposed to solve, anyway.
Presumably the problem that programs store temp files in /tmp, where they
can be deleted by anyone?  The obvious solution is to fix the programs.
It would certainly possible for AT&T to give each user his or her own
temporary directory and to modify the standard System V programs to use
this directory.  Third party software might continue to use /tmp for a
long time (old binaries and all that), but is the /tmp problem really all
that pressing?  We've lived with /tmp for the last 20 years; just how
awful would it be if a few programs continued to use it for the next
few?  And even with this sticky bit "feature" /tmp can still be attacked
by immature users; just create enough files there and the access time will
increase to unacceptable levels.
					Kenneth Almquist