Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!ncifcrf!nlm-mcs!adm!smoke!ibd!heilpern
From: heilpern@ibd.BRL.MIL (Mark A. Heilpern )
Newsgroups: comp.unix.questions
Subject: Re: File Write Permission Rules
Keywords: file write permission rules
Message-ID: <249@ibd.BRL.MIL>
Date: 9 Feb 89 13:05:45 GMT
References: <306@wubios.wustl.edu>
Reply-To: heilpern@brl.arpa (Mark A. Heilpern (IBD) <heilpern>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <306@wubios.wustl.edu> david@wubios.wustl.edu (David J. 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.

In order to disallow 'removal-of-file' positions, you must remove write
protection from the directory. By removing a file, you are not writing
to the file, or altering it in ANY way, you are merely removing the link
to the file, which means you are writing to the directory which has
that link.
-- 
 |\/|         |
 |  |   _     |<
/    \_(_(_)\_/ \______