Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!edcastle!aiai!richard
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.os.minix
Subject: Re: Security hole ?!
Keywords: Program: rm"
Message-ID: <4441@skye.ed.ac.uk>
Date: 9 Apr 91 12:08:47 GMT
References: <553@ultrix.uhasun.hartford.edu>
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 29

In article <553@ultrix.uhasun.hartford.edu> mgallagh@uhasun.hartford.edu (Michael Gallagher) writes:
>   Using two accts that were not priv'd, I found that while files created
>by one could not be read, etc with by the other if protections were not set
>for world or group [umask = 77], they COULD be rm'd. 

Unix allows you to remove a file if you have write permission on the
directory containing the file.  The permissions on the file itself are
irrelevant, but rm warns you on the grounds that you might be making
a mistake.

>    This would seem to me to be a potential problem. i.e., files that must
>stay world-readable, such as  passwd could be erased....

/etc is not normally world-writable, so you should not be able to remove
/etc/passwd.  If you can, then either the permissions on /etc are wrong,
or you really have a bug (not in rm, but in the operating system).

>    Anyone know why this would be the case?? I suppose one could just 
>patch rm & re-compile it, but I'm surprised that it is set as such.

A change to rm would be useless, since one could just write one's own
version.  The protection is implemented by the file system, not the
application.

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin