hood@uiucuxc.UUCP (01/14/84)
#N:uiucuxc:10900003:000:773 uiucuxc!hood Jan 13 08:52:00 1984 This is more-than-likely a hardware bug, but ... I'm running XENIX 1.3 on a Radio Shack Model 16B, this is reported to be a close copy (and truncated) version of v7. 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 . . . Has *anyone* seen anything like this ? Can anyone point me to someone with some answers (perhaps at trsvax). My dealing over the phone to the system guys at RS has caused me to crash my system. Emmet P Gray
mark@laidbak.UUCP (Mark Brukhartz) (01/15/84)
> 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
guy@rlgvax.UUCP (Guy Harris) (01/16/84)
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