Path: utzoo!attcan!uunet!convex!killer!ames!mailrus!tut.cis.ohio-state.edu!uccba!alobar!grs
From: grs@alobar.ATT.COM (Gregg Siegfried)
Newsgroups: comp.unix.wizards
Subject: Re: Nasty Security Hole?
Summary: SVR3.2 and 4.0 rm
Keywords: mail permissions security
Message-ID: <1031@alobar.ATT.COM>
Date: 19 Nov 88 04:02:24 GMT
References: <175@ernie.NECAM.COM> <189@wyn386.UUCP> <2955@ingr.UUCP>
Reply-To: grs@alobar.ATT.COM (Gregg Siegfried)
Distribution: na
Organization: AT&T OSS Development, Cincinnati
Lines: 20

In article <2955@ingr.UUCP> crossgl@ingr.UUCP (Gordon Cross) writes:
>If you have write access to a directory, you can remove any file it contains
>regardless of the permissions set for that file.  This "feature" is not a
>security hole even though it would seem so.  I have never liked the way it
>works either since I occasionally desire to protect a file from accidental
>deletion (as one can under VMS).  At least rm does ask...

This discussion seems to arise fairly frequently in some of these newsgroups.
I think it's worthwhile to note that in SVR3.2 (and presumably 4.0) this
is no longer necessarily the case.  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.

I know that /tmp and /usr/tmp are configured this way by default in 3.2.

>Gordon Cross

Gregg Siegfried
grs@alobar.att.com
AT&T doesn't speak for me, nor I for them.