This bug has appeared between lpr 0.31 and lpr 0.33. lpr -r -s file is supposed to make the data file in the print queue a symbolic link to the actual file and then to remove the file after being printed. Running lpr -r -s file puts the correct U entries into the printer control file, but lpd does not pay attention to them. The reason is that someone added explicit code to lpd/printjob.c to suppress removal of files specified in the control file with absolute pathnames. The following somewhat suspect patch "fixes" this problem. The reason that I say it is somewhat suspect is that it removes code that was added between 0.31 and 0.33. I can find no documentation as to why the code was added. The reason I entered this bug as high severity is that there is no workaround for this problem. We have software that relies on this documented behavior of lpr/lpd to avoid filling the disk when automatically generating files to print. The only I have been able to get that functionality at this point is to modify lpd to reintroduce this feature. Note that the behavior desired by lpr -r -s is as described in the lpr manual page. Here's my patch. --- lpd/printjob.c.qdist Thu Oct 1 16:15:50 1998 +++ lpd/printjob.c Wed Jan 6 17:07:54 1999 @@ -470,8 +470,6 @@ continue; case 'U': - if (strchr(line+1, '/')) - continue; (void) unlinkfile(line+1, fromhost, logname); } /* @@ -941,7 +939,7 @@ } while (getline(cfp)) - if (line[0] == 'U' && !strchr(line+1, '/')) + if (line[0] == 'U') (void) unlinkfile(line+1, from, logname); /* * clean-up in case another control file exists
One additional note: if the code to disable removal of files specified with absolute paths was intentional for security concerns, it was incomplete. The function process() in common_source/rmjob.c does not suppress this. That means that if you lpr -r -s file and then lprm the job before it prints, the file will be removed. This actually happens -- I've tested it. I don't think this is a security issue because the lpr code checks to ensure that the file is local and assumes the uid and login gid of the user on whose behalf the print job is being run. This is easy to reproduce. I don't think it is a bug, but I am mentioning it because it adds credibility to the notion that the problem I reported is a bug rather than an intentional change in the funcionality. --ejb
My patch opens up a security hole through which any user can cause deletion of any file on a print server that accepts connections from their host. All one has to do is feed the lpd a control file that has the suitable remove entry in it. This hole is closed by the two lines which my patch attempts to remove. This bug in its present form should therefore be cancelled. Instead, the problem is that lpr -r -s no longer works but is still documented to work. I will generate a new bug report about that. Sorry for the runaround on this. What a shame that such useful functionality is no longer possible due to this exploit. I was able to write a perl script in less than 20 minutes that would delete an arbitrary remote file on a machine running lpd as patched according to my suggestion.
*** Bug 717 has been marked as a duplicate of this bug. *** lpr -r -s file no longer causes deletion of file from the queue. The reason for this is that the code that was responsible for this behavior has been disabled since it also made lpd vulnerable to exploit by a remote user who could cause any file on the print server to be deleted. This is probably the same case as the most recent CERT advisory on BSD line printing daemon. Unfortuantely, I wasted a day rediscovering this myself. :-( See bug 717 (which is now obsolete and should be cancelled) for details. That bug includes a patch to restore lpr -r -s functionality, but that patch re-introduces this security hole into lpd.
the man page has been fixed in lpr-0.34-2