Path: utzoo!attcan!uunet!husc6!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: rm etc. (was: Nasty Security Hole?)
Message-ID: <8941@smoke.BRL.MIL>
Date: 20 Nov 88 02:29:46 GMT
References: <175@ernie.NECAM.COM> <189@wyn386.UUCP> <8910@smoke.BRL.MIL> <118@hudson.Morgan.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: na
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

In article <118@hudson.Morgan.COM> frank@Morgan.COM (Frank Wortner) writes:
>In article <8910@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>}Inode permissions apply to the contents of the inode, not to
>}links to it (which are contained in other inodes).
>Perhaps I've failed to understand what you wrote.  I've always thought that
>non-symbolic links were directory entries pointing to the *same* inode, and
>that any permissions (read, write, and execute of the underlying object)
>were shared by all links.

No, the link can be altered independently of permissions on the inode
to which it is a link.  The link is an object (directory entry) that
is a piece of another object (the directory) separate from the inode
object.  The inode itself can be read, written, executed, etc. only
in accordance with the permissions attached to IT, whereas links to
the inode are controlled by the permissions attached to their
containers (directories).  The one extra wrinkle is that space used
by an inode is reclaimed when it becomes totally inaccessible (last
link to it is removed).  All implementations of "symbolic links" that
I know of are broken in this regard; even though symbolic links to an
inode exist, the inode will vanish when all its "hard" links are
removed (and the last open file table entry associated with it is
closed).

A utility such as "rm" COULD perform extra checks based on the inode
permissions.  In fact the 4.nBSD "rm" does this ("override permissions
on xxx?") and it is EXTREMELY annoying.