hazards of linking directories

[William L. Sebok]

1) In 4.2 BSD the sequence 
	ln -s directory linkfile
	rm -rf linkfile
 will delete the symbolic link "linkfile" but leave directory "directory" and 
 its children intact.

 Thus:
	ln -s / linkfile
	rm -rf linkfile

 is perfectly safe.

2)
> A few months ago, being short on disk space, I decided that I would
> link /usr/src/uts/h to /usr/include, and save myself 1200 blocks.
> This required setuid privs to link the directories, but being of the
> age of consent, I did it.  Now, as cpio goes depositing files in a
> tree, it climbs the tree by itself using a cd routine, rather than
> depositing each file from the root.  So cpio puts some files in
> /usr/include, cd's to ../.., which it thinks is root, but is actually
> ../.. relative to /usr/src/uts/h, that being /usr/src.  Poof.
>	.... 
> Might this have some effect on systems that have symbolic links to
> directories?  Symbolic links (4.2) and cpio (System N) have been
> pretty mutually exclusive, but it's worth a thought.
> 	Andy Tannenbaum   Masscomp Inc  Westford MA   (617) 692-6200 x274

Yes, in the presence of symbolic links one cannot assume that
	cd directory
	cd ..
will bring you back to where you started.  Programs just have to keep this
in mind.  In general one probably wants an option anyway in one's tape archiving
program whether or not to follow a symbolic link.  Otherwise many directory
subtrees will get dumped twice.

I consider neither of these two points a security issue.

I have found symbolic links to directories an extremely nice thing to have.
It gives a system manager a great deal more flexiblity in where to put things.
For example, when I get some wonderful new software but filesystem /usr/src
is full I can place it somewhere on the big user filesystem /mnt and place
a symbolic link on /usr/src to it.  That way it can be still found by someone
expecting to find it in /usr/src.  When the disk in which /usr/lib/news
resided began to go back and give extremely strange news core dumps I used
a symbolic link to place this directory on another disk and verify that
indeed it was the disk at fault.
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls