Path: utzoo!attcan!uunet!peregrine!elroy!ames!haven!mimsy!aplcen!aplcomm!trn@aplcomm.jhuapl.edu
From: trn@aplcomm.jhuapl.edu (Tony Nardo)
Newsgroups: comp.unix.wizards
Subject: delete permissive (Re: Nasty Security Hole?)
Keywords: permissions
Message-ID: <2521@aplcomm.jhuapl.edu>
Date: 22 Nov 88 15:04:27 GMT
References: <175@ernie.NECAM.COM> <189@wyn386.UUCP> <2470@aplcomm.jhuapl.edu> <8927@smoke.BRL.MIL> <6521@galbp.LBP.HARRIS.COM>
Sender: news@aplcomm.jhuapl.edu
Reply-To: trn@aplcomm.jhuapl.edu (Tony Nardo)
Distribution: na
Organization: Johns Hopkins University/APL (Baltimore, Md.)
Lines: 44

In article <6521@galbp.LBP.HARRIS.COM> mhw@wittsend.UUCP (Michael H. Warfield (Mike)) writes:
>In article <8927@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>In article <2470@aplcomm.jhuapl.edu> trn%warper.jhuapl.edu@aplvax.jhuapl.edu (Tony Nardo) writes:
>>>A pity the implementers of UNIX didn't borrow one the idea of having a
>>>separate "delete" bit.  It's one of a number of DEC features I miss.
>
>>What in the world would it MEAN?  It is the DIRECTORY that is modified
>>by an unlink, not the inode.  Would a "delete" bit then mean that no
>>links to the inode could be removed?  Think about the consequences for
>>a bit.  It would be horrible!
>
>     Nope.  Sound great as long as it was in addition to directory permissions
>and not instead of directory permissions.  Doesn't sound too good when you
>say you will allow or disallow delete permission on all the files in a directory
>regardless of the nature of the individual files.  Maybe some of the definition
>needs refining but it sure could fix more problems than it casues!

Thank you, Michael.  I was going to say the same thing, but not so briefly.

unlink() would admittedly have to perform the grueling :-) task of seeing if
the proper "d" permissive was set for the file.  If it isn't set, you can't
unlink it.  "rm" would then need to report that a file could not be unlinked
(or ask the user to override, in which case it has to mask in the proper "d"
bit).

It is rather inconsistent to allow file-dependent permissives for reading,
writing, and execution but NOT for file deletion.

Sheesh.  What was so hard about implementing
	-rwxdr---r---
instead of
	-rwx-r--r--
for the file permissives?


Too late now...

==============================================================================
ARPA, BITNET:   trn@aplcomm.jhuapl.edu
UUCP:		{backbone!}mimsy!aplcomm!trn

50% of my opinions are claimed by various federal, state and local governments.
The other 50% are mine to dispense with as I see fit.
==============================================================================