Xref: utzoo comp.unix.wizards:22951 alt.security:1126
Path: utzoo!mnetor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!unisoft!greywolf
From: greywolf@unisoft.UUCP (The Grey Wolf)
Newsgroups: comp.unix.wizards,alt.security
Subject: Re: Hard links to directories: why not?
Keywords: ln, directories, security...
Message-ID: <3070@unisoft.UUCP>
Date: 19 Jul 90 18:04:39 GMT
References: <5222@milton.u.washington.edu> <1990Jul18.235607.19403@virtech.uucp>
Reply-To: greywolf@unisoft.UUCP (The Grey Wolf)
Organization: Foo Bar and Grill
Lines: 66

In article <1990Jul18.235607.19403@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>In article <5222@milton.u.washington.edu> wiml@milton.u.washington.edu (William Lewis) writes:
>>
>>   In the man entry for ln(1) (and for link(2)),  it says that
>>hard links may not be made to directories, unless the linker is
>>the super-user (in order to make '.' and '..', I suppose). My 
>>question is: why not? (and is there any reason that I, if I'm
>>root, shouldn't do this?) It seems perfectly harmless to me, although 
>>it would allow the user to make a pretty convoluted directory structure,
>
[ some stuff about find deleted... ]
>
>Now you might say that you don't care that much about find.  That is, you 
>might say this until you realize that find is used as a main portion of the
>backup scheme on many systems, so your backups will get screwed up.

Outside of the fact that "dump" *should* be the way to go to back up
systems (religious issue -- flames to Email!), the problem with hard-
linking directories is indeed a security issue at one point.
Consider the user who knows that he is chroot(2)ed somewhere.  If he could,
via another account, make a hard link to somewhere upward of his chroot(2)ed
point (assuming that his new root is not the root of a separate file system)
then he could access things he wasn't meant to.

Another claim is somewhere in the rename(2) man page:

"CAVEAT
    The system can deadlock if a loop in the file system graph
    is present.  This loop takes the form of an entry in direc-
    tory "a", say "a/foo", being a hard link to directory "b",
    and an entry in directory "b", say "b/bar", being a hard
    link to directory "a".  When such a loop exists and two
    separate processes attempt to perform "rename a/foo b/bar"
    and "rename b/bar a/foo", respectively, the system may dead-
    lock attempting to lock both directories for modification.
    Hard links to directories should be replaced by symbolic
    links by the system administrator."

>>that's the user's priviledge. So I suppose it's probably a security
>>issue somehow (restrictions of this sort seem to be). Hence the
>>crosspost to alt.security. 

Well, it IS the user's privilege to make up a convoluted directory struc-
ture in his own namespace, but using symbolic links.  They're much more
easy to try and resolve, since you don't have to do an ncheck to find out
which directories have such-and-such an inode.

Now, WHY a user would need to make a namespace convoluted escapes me, but
the world is full of oddities, now, ain't it?

>>-- 
>>wiml@blake.acs.washington.edu       Seattle, Washington  | No sig under
>>(William Lewis)  |  47 41' 15" N   122 42' 58" W  |||||||| construction
>
>
>-- 
>Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
>uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
>                                                Sterling, VA 22170 


-- 
-- once bitten, twice shy, thrice stupid --
MORALITY IS THE BIGGEST DETRIMENT TO OPEN COMMUNICATION.
/earth: minimum percentage of free space changes from 10% to 0%
should optimize for space^H^H^H^H^Hintelligence with minfree < 10%