Path: utzoo!attcan!uunet!mcvax!ukc!warwick!mirk
From: mirk@warwick.UUCP (Mike Taylor)
Newsgroups: comp.unix.questions
Subject: Re: File Write Permission Rules
Summary: Nope, Thompson & Ritchie got it write(sic)
Keywords: file write permission rules
Message-ID: <1177@ubu.warwick.UUCP>
Date: 14 Feb 89 14:00:54 GMT
References: <306@wubios.wustl.edu>
Sender: news@warwick.UUCP
Reply-To: mirk@uk.ac.warwick.cs (Mike Taylor)
Organization: Computer Science, Warwick University, UK
Lines: 37

In article <306@wubios.wustl.edu> david@wubios.wustl.edu (David Camp) writes:
>We have a strange situation where a program can write to a file even
>though it does not have write permission.  What it does is remove the
>file and write a new one in its place.  It can do this because it has
>write permission to the directory in which the file is contained.
>
>My question is:  What is the (historical or otherwise) justification for
>this rule?  It seems wrong.  I would have required write permission to
>the file itself in order that it be removed.

Aha!  Henry Spencer's classic line strikes yet again: "Those who do
not understand UNIX are condemned to re-invent it, poorly".  There are
no design flaws of this level of simplicity in UNIX (OK, so it's a
sweeping statemnt, but that's OK, 'cos it's also a true one (1/2 a :-))
The way UNIX handles these things is about as flexible and intuitive
as it is possible to be, (though I'll admit it had me a bit confused
when I started off)

Think of a directory as a listing of the files that make up its
contents.  Then to write to the directory is to change this list - ie,
to add to it, delete from it, alter a name, change permissions on a
file or whatever.  To do these things, you need write permission on a
directory.  To change the actual contents of a file, you need write
permission to the file.  To do what you suggested above, (ie. removing
the file and creating a new one with the same name) might *look* like
it's the same file, but is actually a different one.

Consider, for example, the fact that the shell "/bin/sh" is (on most
systems) owned by root, but in the directory /bin owned by bin.  Bin
cannot change the shell binary, but can replace it with a new one.
However, if this happens, it will be clear to all and sundry that the
user with access to the "bin" account has been a naughty boy.  (Mind
you, we all keep our "bin" accounts nice and secure, don't we? :-)
______________________________________________________________________________
Mike Taylor - {Christ,M{athemat,us}ic}ian ...  Email to: mirk@uk.ac.warwick.cs
"Some folks lives roll easy as a breeze ...  Drifting through a summer night."
------------------------------------------------------------------------------