Bug 717

Summary:	lpr -r -s file does not remove file when finished printing
Product:	[Retired] Red Hat Linux	Reporter:	Jay Berkenbilt <ejb>
Component:	lpr	Assignee:	Crutcher Dunnavant <crutcher>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	5.2	CC:	ejb
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	1999-03-19 22:53:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jay Berkenbilt 1999-01-06 22:10:35 UTC

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

Comment 1 Jay Berkenbilt 1999-01-06 22:32:59 UTC

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

Comment 2 Jay Berkenbilt 1999-01-07 04:27:59 UTC

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.

Comment 3 Jeff Johnson 1999-01-07 13:04:59 UTC

*** 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.

Comment 4 Bill Nottingham 1999-03-19 22:53:59 UTC

the man page has been fixed in lpr-0.34-2