Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!usc!ucsd!ucbvax!hplabs!hpfcso!hpfcdc!lienhart
From: lienhart@hpfcdc.HP.COM (Bob Lienhart)
Newsgroups: comp.unix.wizards
Subject: Re: Need help with weird lp problem
Message-ID: <5980063@hpfcdc.HP.COM>
Date: 28 Feb 90 18:20:56 GMT
References: <247@camdev.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 28


The root of the problem here is that user "lp" can not print!
Sounds kind of foolish, but on most systems lp is a pseudo-user.
The problem was introduced when the long-standing defect related
to "I can't print a file that I do not own, but I can read".  This
has been corrected, but now user "lp" can't print.

In the example refered to in the basenote, the interface script with
the remsh call is being executed by user "lp" -- hence the aborted 
execution.  In this case there is a simple fix.  Use the new sys
admin manager program, sam, to delete the old printer.  Then use 
sam again to add a remote printer, choosing the default remote model.
This should work well, especially since the old remsh method already
required proper access on the remote system.

But this problem also shows up in other instances.  If any pre-formatting
is performed by a pseude-printer, for example a troff pre-processor, the
call to an actual printer device will be executed by user "lp".  If this 
happens, then I would suggest the following work around:

			chown lp /usr/bin/lp
			chgrp bin /usr/bin/lp
			chmod 6555 /usr/bin/lp

This will of course break the original fix, but I have seen no further
side effects as of yet.

Bob Lienhart