🚀 go-pugleaf

This looks like an extra link made to "/usr" in "/usr/spool/lpd" (the
"lfaXXXXX" files are made when a print job is queued and the file to
be printed is on the same file system as "/usr/spool/lpd").  The
S3 spooler (the V7 spooler is almost identical) does *not* check whether
a file to be printed is a directory, and it may run set-UID to root, so it
can (and probably will) make a link to that directory in "/usr/spool/lpd"
if that directory is on the same file system.  So if somebody says

	lpr /usr

this could happen, and would confuse the heck out of UNIX.  Those spoolers
should probably be modified to refuse to print a directory - since directories
are binary files, I can't imagine any printer which would do something
meaningful if you shoved the contents of that directory file a byte at a time
to them.  Any other spoolers which make links like this should also be fixed
in the same fashion.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy

>	Now for the problem : I have found an extremely large file nested within
>	the usr/spool directory.  This file seems to be nothing more than a 
>	directory within a directory within a directory, ad infinitum.
>	It goes like this ...
>	
>		/usr/spool/lpd
>		/usr/spool/lpd/lfa00047
>		/usr/spool/lpd/lfa00047/spool
>		/usr/spool/lpd/lfa00047/spool/lpd
>		/usr/spool/lpd/lfa00047/spool/lpd/lfa00047
>			.
>			.
>			.

You have a link from /usr/spool/lpd/lfa00047/spool back to /usr/spool. The
easiest way to fix this is with the trivial program:

	main()
	{
		unlink("/usr/spool/lpd/lfa00047/spool");
		exit(0);
	}

This will break the link (leaving /usr/spool otherwise intact). I suggest
running fsck (or icheck and dcheck) to check the filesystem after the fix.

While Unix does prohibit random links to directories, this restriction is
enforced outside of the kernel. Only the super-user is allowed to create,
remove and link directories. Mkdir(1) and rmdir(1) are set-user-id to root.
After making a truly empty directory with mknod(2), mkdir(1) creates links
to itself and its parent directory ("." and "..", respectively). This way,
the kernel does not know that "." and ".." are at all special (except for
an obscure chroot(2) kludge).

				Mark Brukhartz
			{allegra,ihnp4,ittral,trsvax}!laidbak!mark

Actually, the chroot kludge (which isn't present in vanilla V7, but is in
both Berkeley and USG releases of UNIX) plugs a security hole.  "." and ".."
have been getting more special over time; they are *very* special in 4.2BSD,
as the "mkdir" and "rmdir" system calls have to know about them, and the
"rename" system call, which allows you to rename directories and is not
privileged, treats them specially as well.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy