Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!thestepchild!rhartman
From: rhartman@thestepchild.sgi.com (Robert Hartman)
Newsgroups: comp.unix.shell
Subject: Re: SCCS and RCS over NFS (was: Creating a lock file in sh?)
Message-ID: <1991Apr23.183941.22750@odin.corp.sgi.com>
Date: 23 Apr 91 18:39:41 GMT
References: <1991Apr20.020506.8656@twinsun.com> <28124072.1774@tct.com> <1991Apr22.175620.8054@chinet.chi.il.us>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 43

In article <1991Apr22.175620.8054@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>In article <28124072.1774@tct.com> chip@tct.com (Chip Salzenberg) writes:
>>>For example (Bourne shell):
>>>
>>>	if (umask 777;  echo >lock)
>>>	then
>>>		Perform whatever operation required locking.
>>>	...
>>
>>Unfortunately, this method is still prone to spurious failure when an
>>imperfect network loses the ACK from the initial creation attempt.
>
>
> ... However, won't this always break when run by root?
>
>Les Mikesell
>  les@chinet.chi.il.us

Hmm.  Seems to fail when I run it as root.  For a while this example
had me stymied because it seemed to belie my earlier contention that
deletion/truncation is a separate type of file access.  If write
permission could protect a file from truncation, then my thinking said
that perhaps denying write permission would be sufficient to cover cases
of truncation, and denying write permission on the directory would be
sufficient to cover cases of deletion (even though rm -f overrides it,
but then, you're suppoed to know what you're doing, right?).

However, write permission does not protect a file from truncation by
root.  Perhaps it should.  But I'm sure there are good reasons why it
doesn't.  And, it also can be argued that protecting a file from
spurious deletion is not the job of a directory's permission bits.  It
ought to be the job of the file's permission bits.  Also, although
truncation can be considered a form of "writing" on a file, it is of a
different sort than editing.  It could go either way, but functionally,
from the user's standpoint, truncation is more closely related to
deletion than it is to editing, even if, from the OS's standpoint, it
is implemented as a write operation.

So, I'm back to the opinion that deletion/truncation is a separate type
of file access, and should (someday) be protected by it's own set of 
permission modes.  I'm not, however, holding my breath.  All this is IMHO.

-r