hazards of linking directories

[trb at masscomp.UUCP]

First, the experience of one of our customers, second, my experience
of the past two days.

One of our customers typed:

	% lpr /

Sounds harmless enough, right?  Lpr is a spooler which links the file
you printed (root here) into /usr/spool/lpr/<linktofile>.  Lpr is
setuid to root because it has to be able to link people's protected
files to its spool directory for later printing.

When lpr tried to unlink <linktofile>, it couldn't, of course, because
it was a directory and there were (lots of) files in it.  So lpr left
it there.  Later that evening, the customer's cron entry which cleans
up the file systems looked for orphaned files in the spool directories,
assumed to be left by glitches such as system crashes.  It did an rm
-rf /usr/spool/lpr/<linktofile> and yes, you guessed it.  The next
morning, there were no (count 'em) files left in the file system.

Second, my experience.

I had been having trouble lately with cpio, files were allegedly being
written, but I couldn't find them.  I know for a fact that if a cpio
input stream is at all in error, cpio gets checksum and phase errors.
No such luck here, the files were just not showing up, though cpio
claimed to be writing them.

I put debugging statements all through cpio, and sure enough, it was
writing all my files, with valid counts, valid names, creating the
directories, and not unlinking anything it shouldn't have.

Finally, I decided to grep through my nightly find / -print logs.  The
file, /install/foo, showed up in /usr/src/install/foo.  Oh no.  Here's
what happened:

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.

To quote from the System V manual:

	Link and unlink perform their respective system calls on their
	arguments, abandoning all error checking.  These commands may
	only be executed by the super-user, who (it is hoped) knows
	what he or she is doing.

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