robert@pvab.UUCP (Robert Claeson) (09/06/87)
The System V print spooler runs as a SUID 'lp' command, which
means that the files I want to print must be readable by others or,
if I'm lucky, by the group. This implies that anyone on the system
will be able to print, copy or read the files I want to be able
to print.
Please don't mention crypt(1) as a solution if I have data I want to
keep secret in my files. Crypt is
a) rather easy to break
and
b) not distributed with the UNIX versions exported from the USA, and
I'm using such an export version.
Shouldn't the System V print spooler be considered as a serious security
hole? Will it ever fit into a "secret" UNIX system? I understand that Gould,
Sun and the other vendors working on secret UNIX systems use the BSD spooler.
--
SNAIL: Robert Claeson, PVAB, P.O. Box 4040, S-171 04 Solna, Sweden
UUCP: {seismo,mcvax,munnari}!enea!pvab!robert
ARPA: enea!pvab!robert@seismo.arpajv@mhres.mh.nl (Johan Vromans) (09/07/87)
In article <313@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: >The System V print spooler runs as a SUID 'lp' command, which >means that the files I want to print must be readable by others ... I have encountered this question very often, and there is an easy solution to it. Instead of using "lp filename" (which indeed requires the indicated path to be accessible by the lp owner), you can use "lp < filename". If you can read the file, you can print it this way. >Shouldn't the System V print spooler be considered as a serious security >hole? Don't think so. See the above solution. > Will it ever fit into a "secret" UNIX system? ^^^^^^ I quess you mean "secure" UNIX. Although a "secret" UNIX could be interesting ... -- Johan Vromans | jv@mh.nl via European backbone Multihouse N.V., Gouda, the Netherlands | uucp: ..{?????!}mcvax!mh.nl!jv "It is better to light a candle than to curse the darkness"
scl@virginia.acc.virginia.edu (Steve Losen) (09/07/87)
Files do not need to be readable by "other" to print with lp. Just invoke like this: lp < filename Your shell opens the file before invoking lp which simply reads stdin. -- Steve Losen University of Virginia Academic Computing Center
philip@axis.fr (Philip Peake) (09/07/87)
In article <313@pvab.UUCP>, robert@pvab.UUCP (Robert Claeson) writes: > The System V print spooler runs as a SUID 'lp' command, which > means that the files I want to print must be readable by others or, > if I'm lucky, by the group. This implies that anyone on the system > will be able to print, copy or read the files I want to be able > to print. You feed your program to lp on its standard input. Only you have to be able to read the file to do this. The file will then be copied into a spool directory readable only by lp. No problem. Philip
larry@kitty.UUCP (Larry Lippman) (09/08/87)
In article <1284@mhres.mh.nl>, jv@mhres.mh.nl (Johan Vromans) writes: > >The System V print spooler runs as a SUID 'lp' command, which > >means that the files I want to print must be readable by others ... > > I have encountered this question very often, and there is an easy > solution to it. Instead of using "lp filename" (which indeed requires the > indicated path to be accessible by the lp owner), you can use > "lp < filename". If you can read the file, you can print it this way. Many "project" directories on our systems contain files which are not readable by "lp", so we have implemented some simple shell scripts in /usr/local/bin which take filenames as arguments, feed them to pr(1), and pipe them to lp(1). This makes the above rather simple; as a result, we almost never invoke lp(1) per se. > >Shouldn't the System V print spooler be considered as a serious security > >hole? > > Don't think so. See the above solution. Temporary files which are queued pending printing are contained in /usr/spool/lp/request/printer_name/job_id with permissions of 440 and owner of "lp" and group of "bin". This is reasonably secure, in case anyone was wondering. I personally find the Sys V lp spooler to be very useful and flexible, and offer the following suggestions for greater versatility. These are some non-obvious application possibilities (at least non-obvious to a beginner from reading the documentation). 1. There is no reason why more than one printer name cannot be associated with _one_ physical printer using _one_ physical I/O port. The usefulness here is to invoke the _same_ printer in a different fashion merely by specifying a different printer name as an lp(1) argument. For example, one name will invoke a laser printer for landscape printing (132 cols wide), with another name will invoke the laser printer for portrait printing (80 cols wide). The different setup commands for the laser printer are contained in the individual /usr/spool/lp/interface/printer_name shell scripts. 2. The lp spooler works fine with plotters and other display devices, and will pass 8-bit data from specified files very nicely. Some customization of the interface shell script is obviously required - but that is a relatively simple task. Once in that interface shell script, you can invoke custom programs before, during and after a printing (or plotting) job. 3. The lp spooler is an ideal way to manage terminals with printers connected to their aux ports. Using lpadmin(1M), create a printer name associated with a specific tty port. The interface shell script should contain the escape sequences necessary to turn on the aux port, print the job, and then restore the terminal. I find this to be much more convenient than using the printing function keys on a terminal. The above applications can all be implemented using the lpadmin(1M) lp spooler administration command. Some "high level" printer administration programs - AT&T UNIX PC, NCR Tower, etc. - will not permit the above implementations, so you will have to use lpadmin(1M) by hand. As a further example of lp spooler flexibility, we have - believe it or not - used the lp spooler to control a speech synthesizer for warning messages, and to control a storage and retrieval robot. <> Larry Lippman @ Recognition Research Corp., Clarence, New York <> UUCP: {allegra|ames|boulder|decvax|rutgers|watmath}!sunybcs!kitty!larry <> VOICE: 716/688-1231 {hplabs|ihnp4|mtune|seismo|utzoo}!/ <> FAX: 716/741-9635 {G1,G2,G3 modes} "Have you hugged your cat today?"
pls@sortac.UUCP (Pat Sullivan) (09/08/87)
In article <313@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: >The System V print spooler runs as a SUID 'lp' command, which >means that the files I want to print must be readable by others or, >if I'm lucky, by the group. This implies that anyone on the system >will be able to print, copy or read the files ... Not really; all you need to do is "lp < secretstuff". You should be aware, however, that lp spools its requests in cat'able files "/usr/spool/lp/request/[class]/d0-[sequence]", but these are normally readable only by user "lp" and group "bin". If you are really paranoid, you can play games to make the "d0-" files nonsense (sorry about crypt ...) - "lp" doesn't care what they contain when it spools them), and put a translator in the printer interface (/usr/spool/lp/interface/[printer]). The translator could be made to work only when the user is "lp" and the output file is your printer. Then you just have to make sure that you get to the printer before anyone else (:-). >SNAIL: Robert Claeson, PVAB, P.O. Box 4040, S-171 04 Solna, Sweden >UUCP: {seismo,mcvax,munnari}!enea!pvab!robert >ARPA: enea!pvab!robert@seismo.arpa My opinions, not AT&T's, etc. etc. ============================================================ Pat Sullivan - {akgua|ihnp4}!sortac!pls - voice 404-257-7382
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (09/08/87)
In article <1986@kitty.UUCP> larry@kitty.UUCP (Larry Lippman) writes: [... other topics ...] |1. There is no reason why more than one printer name cannot be associated |with _one_ physical printer using _one_ physical I/O port. The usefulness |here is to invoke the _same_ printer in a different fashion merely by |specifying a different printer name as an lp(1) argument. For example, This works, but there is a mechanism in place to pass options, which works as well, and allows things to be reconfigured somewhat more easily. | |2. The lp spooler works fine with plotters and other display devices, |and will pass 8-bit data from specified files very nicely. Some customization Good point. Anything may be spooled... another interesting use is to have one login on a remote machine which allows remote execution of 'lp'. This allows spooling on machine A of jobs to be printed on machine B, etc. This can be time restricted if desired. I use this to print things from home on my work machine, rather than carry paper back and forth. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (09/08/87)
In article <193@sortac.UUCP> pls@sortac.UUCP (Pat Sullivan) writes: >In article <313@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: >>The System V print spooler runs as a SUID 'lp' command, which >>means that the files I want to print must be readable by others or, >>if I'm lucky, by the group. This implies that anyone on the system >>will be able to print, copy or read the files ... >Not really; all you need to do is "lp < secretstuff". Sorry, this isn't acceptible. I want to have the file name on the banner page and "lp" has no way of finding out the file name. Why can't lp do some IPC to a priviledged process to tell it to print things? -- ----- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet ----- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET ----- ----- Je parle francais comme une vache espagnole.
jmc@ptsfa.UUCP (Jerry Carlin) (09/09/87)
In article <313@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: >The System V print spooler runs as a SUID 'lp' command, which >means that the files I want to print must be readable by others... It's annoying but you can "cat foo | lp" if you want to print a private file (or create a shell script/function/alias to lp that does the same thing). -- voice: (415) 823-2441 uucp: {ihnp4,lll-crg,ames,qantel,pyramid}!ptsfa!jmc Where am I? In the village. Whose side are you on? That would be telling.
allbery@ncoast.UUCP (Brandon Allbery) (09/09/87)
As quoted from <313@pvab.UUCP> by robert@pvab.UUCP (Robert Claeson): +--------------- | The System V print spooler runs as a SUID 'lp' command, which | means that the files I want to print must be readable by others or, | if I'm lucky, by the group. This implies that anyone on the system | will be able to print, copy or read the files I want to be able | to print. +--------------- Earlier spoolers (i.e. lpr) were setuid root, which is potentially an even bigger security violation... What I don't understand is why the lp command doesn't fork a child connected by a pipe and have the child lose setuid and read the files to be printed, passing the data over the pipe to the parent which spools them. Yes, it's a little slower (one fork per file), but show me the security holes. -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> All opinions in this message are random characters produced when my cat jumped (-: up onto the keyboard of my PC. :-)
mdella@polyslo.UUCP (Marcos R. Della) (09/09/87)
I didn't know about this security hole in the 'lp' program. Does
anyone have more information about this? Soon, we are going to be putting
up a classified "secret" system for processing and if this hole does
exist, then we are going to have some serious problems.
Any followups on this subject would be GREATLY appreciated!
--
...!lll-crg --> !csustan --\ | Whatever I said doesn't
>->!polyslo!caus-dp!root | mean diddly as I forgot
...!ihnp4 --> !csun -----/ | it even before finishing
...!dmsd ----/ | typing it all out!!!daryl@ihlpe.ATT.COM (Daryl Monge) (09/09/87)
In article <193@sortac.UUCP>, pls@sortac.UUCP (Pat Sullivan) writes: > In article <313@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: > >The System V print spooler runs as a SUID 'lp' command, which > >means that the files I want to print must be readable by others > > Not really; all you need to do is "lp < secretstuff". > There were several responses to this, all of which missed the point: in my opinion, THIS IS A BUG IN LP. Lets supply some possible solutions, since this is a more general problem in UNIX land. One possibility is to open the file and fork/exec a subprocess that is setuid that does the I/O. Drawbacks include performance problems. Further comments? Daryl Monge UUCP: ...!ihnp4!ihcae!daryl AT&T CIS: 72717,65 Bell Labs, Naperville, Ill AT&T 312-979-3603
jv@mhres.mh.nl (Johan Vromans) (09/09/87)
In article <7233@e.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: >In article <193@sortac.UUCP> pls@sortac.UUCP (Pat Sullivan) writes: >>Not really; all you need to do is "lp < secretstuff". > >Sorry, this isn't acceptible. I want to have the file name on the >banner page and "lp" has no way of finding out the file name. lp -t filename < filename ? [these are to confuse inews] -- Johan Vromans | jv@mh.nl via European backbone Multihouse N.V., Gouda, the Netherlands | uucp: ..{?????!}mcvax!mh.nl!jv "It is better to light a candle than to curse the darkness"
aegl@root.co.uk (Tony Luck) (09/09/87)
The biggest problem I've noticed with print spoolers is the location of the printer - it doesn't really matter if you have wonderful software security (you can of course print a file that does not have public access simply by saying "lp < file" instead of "lp file" so that you open the file - then "lp" inherits the descriptor) if your print room is open for anyone to wander into - how often have you had to sort through a pile of listings to find your own output - of course you don't read them - do you. But plenty of people do. -Tony Luck
guy@sun.uucp (Guy Harris) (09/09/87)
> There were several responses to this, all of which missed the point: > in my opinion, THIS IS A BUG IN LP. > > Lets supply some possible solutions, since this is a more general problem > in UNIX land. One possibility is to open the file and fork/exec a > subprocess that is setuid that does the I/O. Drawbacks include > performance problems. Another possibility, on systems on which a set-UID program can repeatedly switch between its real and effective UID (this includes System V and 4.[23]BSD, although it's done differently on those two systems), is simply to have "lp" switch to its real UID when it opens the file to be printed and switch back as soon as it's opened. Note, however, that this doesn't handle the case where a link (hard or symbolic) can be made between the spooling directory and the file, and where the spooler takes advantage of this. In this case, the spooler will have to run set-UID "root" in order to be guaranteed to be able to read the file. Then again, I rarely give "lpr" a file name; if the printer is being used as a line printer, I usually feed the file(s) to be printed through "pr", and if it's a "troff" job the file to be printed is some pile of PostScript fed to "lpr" as its standard input. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
randy@chinet.UUCP (Randy Suess) (09/09/87)
In article <7233@e.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: >>Not really; all you need to do is "lp < secretstuff". > >Sorry, this isn't acceptible. I want to have the file name on the >banner page and "lp" has no way of finding out the file name. How bout: 'lp -t"secretstuff" < secretstuff'? -t puts the following argument as the banner on the title page. -- that's the biz, sweetheart..... Randy Suess ..!ihnp4!chinet!randy
gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/09/87)
In article <313@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: >The System V print spooler runs as a SUID 'lp' command, which >means that the files I want to print must be readable by others ... I don't know much about System V "lp" (we use MDQS), but just because the spooler is set-UID non-root does NOT necessarily imply a security hole. System V is capable of switching back and forth between the real UID and the effective UID as required; if the spooler is correctly implemented, it should be able to open your file when you spool it, in order to make a copy without requiring global read permission on the file. (The snarfed-away spool copy should be inaccessible to others.)
dce@mips.UUCP (David Elliott) (09/09/87)
In article <297@axis.fr> philip@axis.fr (Philip Peake) writes: >In article <313@pvab.UUCP>, robert@pvab.UUCP (Robert Claeson) writes: >> The System V print spooler runs as a SUID 'lp' command, which >> means that the files I want to print must be readable by others or, >> if I'm lucky, by the group. This implies that anyone on the system >> will be able to print, copy or read the files I want to be able >> to print. > >You feed your program to lp on its standard input. >Only you have to be able to read the file to do this. >The file will then be copied into a spool directory readable only >by lp. No problem. No problem? Why should we have to workaround a shortcoming of the system? The fact is that there is a bug in the system. The documentation says that lp takes a filename as an argument and prints that file. It doesn't say that it takes the name of a file that the user lp can read and prints it, and you can bet that the original author didn't intend this. Of course, the current lp spooler can't last much longer. With networking gradually working its way into System V, it's worth looking at a nicer printer spooler like the Berkeley spooler or (best of all) MDQS from BRL. -- David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dce
wjc@ho5cad.ATT.COM (09/09/87)
Posting-Front-End: GNU Emacs 18.47.1 of Fri Jun 26 1987 on ho5cad (usg-unix-v) In article <1986@kitty.UUCP> larry@kitty.UUCP (Larry Lippman) writes: >> I personally find the Sys V lp spooler to be very useful and flexible, >> and offer the following suggestions for greater versatility. These are some >> non-obvious application possibilities (at least non-obvious to a beginner >> from reading the documentation). >> To take this a step further than Larry's suggestions, there's no reason you have to limit this to output devices. You can use the lp spooler to take care of anything that you want to happen in a serially controlled manner. For example, you could whip up a few shell scripts that replace the "troff" program (or other resource hog) with a feed into a special class of printers in the lp spooler. These fake printers are just calls back to the real troff program. What that means is that only one user (or "n" users if you allow "n" printers in this fake class) runs troff at a time. Although the user interface could be made to look just like real troff, the permissions problem that started this discussion has to be accounted for. You have to mull this over quite a bit before you can do it without losing your marbles (unless you're already pretty familiar with the administrative side of lp), but the possibilities are fairly wide open. I imagine that similar things could be done with lpr, of course, but I have no familiarity with it. Bill Carpenter (AT&T gateways)!ho5cad!wjc HO 1L-410, (201)949-8392
tgr@picuxa.UUCP (Dr. Emilio Lizardo) (09/09/87)
In article <7233@e.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: | In article <193@sortac.UUCP> pls@sortac.UUCP (Pat Sullivan) writes: | >In article <313@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: | >> | >> [ stuff about lp'd files must be readable; hence, no security | >> | >Not really; all you need to do is "lp < secretstuff". | | Sorry, this isn't acceptible. I want to have the file name on the | banner page and "lp" has no way of finding out the file name. Sorry, not an acceptable exception. Use "lp -tfile <file" to banner the filename. If that's too much typing, write an alias into your environment. | Why can't lp do some IPC to a priviledged process to tell it | to print things? If not done correctly, this would allow anyone to print any file! The security exists (although you have to do some extra work to get it); why kludge the code and add more processes when you can hack the stuff into your shell? Seriously, in our environment, the biggest security hole caused by lp is usually because the sysadm didn't disable the password entry for lp (or bin or daemon or ...). -- Tom Gillespie ( ...ihnp4!picuxa!tgr) | (attmail!tgillespie) (201) 952-1178 AT&T/EDS Product Integration Center 299 Jefferson Rd. Parsippany NJ 07054 "Don't take life so serious ... it ain't nohow permanent." -- Walt Kelly
geoff@desint.UUCP (Geoff Kuenning) (09/10/87)
In article <193@sortac.UUCP> pls@sortac.UUCP (Pat Sullivan) writes: > "/usr/spool/lp/request/[class]/d0-[sequence]", but these are normally > readable only by user "lp" and group "bin". Unfortunately, of course, the spooler itself is user "lp". So you can do: % lpstat -t % (note sequence numbers of requests were spooled by user xxx) % lp -dfast-printer /usr/spool/lp/request/[class]/d0-[sequence] and, with a little bit of luck and a long queue on the original printer, you can get a listing of a file you shouldn't be able to read. BTW, note that the orignal poster's problem can be solved (except for the above) by simply specifying the "-c" switch to lp; this even handles banners. Or you can specify the banner with the "-t" switch. (RTFM!) -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
root@hobbes.UUCP (John Plocher) (09/10/87)
+---- David Herron writes the following in article <7233@e.ms.uky.edu> ---- | >Not really; all you need to do is "lp < secretstuff". | | Sorry, this isn't acceptible. I want to have the file name on the | banner page and "lp" has no way of finding out the file name. | | Why can't lp do some IPC to a priviledged process to tell it | to print things? +---- fer chrissakes! try this: : # # This is a sample file called ~/bin/print, mode 755 # /usr/bin/lp -t$1 < $1 invoke as "print file" rename it to "lp", make sure ~/bin in in your path before /usr/bin, and then invoke as "lp file". why bother with IPC et al? -John -- John Plocher uwvax!geowhiz!uwspan!plocher plocher%uwspan.UUCP@uwvax.CS.WISC.EDU
robert@pvab.UUCP (Robert Claeson) (09/10/87)
In article <7233@e.ms.uky.edu>, david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: > In article <193@sortac.UUCP> pls@sortac.UUCP (Pat Sullivan) writes: > >In article <313@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: > >>... anyone on the system > >>will be able to print, copy or read the files ... > >Not really; all you need to do is "lp < secretstuff". > Sorry, this isn't acceptible. I want to have the file name on the > banner page and "lp" has no way of finding out the file name. > > Why can't lp do some IPC to a priviledged process to tell it > to print things? Yeah, have it talk to Berkeley's 'lpd' daemon. Then it will be able to spool things over the network to other hosts, communication servers or printer servers too. -- Robert Claeson, System Administrator, PVAB, Box 4040, S-171 04 Solna, Sweden eunet: robert@pvab uucp: sun!enea!pvab!robert
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (09/10/87)
Try this function:
mylp() { for name in $*; do lp -t "$name" < "$name"; done; }
It also works on multiple files, etc.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mevasoll@a.cs.okstate.edu (Mark Vasoll) (09/10/87)
I've been reading about the various uses that people have dreamed
up for System V lp and thought I would contribute my own...
I wrote an interface module that will open an outbound async port
(ala UUCP style) and execute a script controlled conversation with
whatever might be there (e.g. a "smart" modem, a data switch, etc.,
in our case a Case Communications DCX 850) to establish a connection
to the destination printer, print the job, then return to the script
for any needed "disconnect" conversation (reseting the modem or whatever).
With this and it's compliment that a friend of mine wrote for VAX/VMS's
Symbiont modification facilities, we can have printers all across campus
that are simply attached to our data switch and are shared between all
UNIX System V and VMS systems.
Another interface we did is somewhat stranger. It packages up the
print job as a mail message and mails it to a remote VMS system
that is equipt with VMS/PMDF, which then uses the DELIVER facility
(provided as part of the PMDF distribution) to unpack the job and
issue a PRINT command with the /switches coming from the subject
line of the message. This one is just a shell script on the UNIX
system and a .COM file on the VMS system.
All of this can be made available, after a little more testing,
if there is any interest.
Cheers,
--
Mark Vasoll
Computing and Information Sciences Internet: vasoll@a.cs.okstate.edu
Oklahoma State University UUCP: {cbosgd, ihnp4, rutgers, seismo,
Stillwater, Oklahoma uiucdcs}!okstate!vasollschwartz@gondor.psu.edu (Scott E. Schwartz) (09/10/87)
In article <214@ho7cad.ATT.COM> wjc@ho5cad.ATT.COM writes: >To take this a step further than Larry's suggestions, there's no >reason you have to limit this to output devices. You can use the lp >spooler to take care of anything that you want to happen in a serially >controlled manner. % setenv HUMOR medium Yup, and you could call it batch processing. While i agree that there is probably a need for a tool like this in unix (here at PSU there is a locally generated one called `batch') it strikes me as funny to tout it as a feature of the unix spooler, considering that unix was designed to be and stands out for being a highly interactive environment. -- Scott Schwartz schwartz@gondor.psu.edu
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (09/10/87)
In article <2916@psuvax1.psu.edu> schwartz@gondor.psu.edu (Scott E. Schwartz) writes: >In article <214@ho7cad.ATT.COM> wjc@ho5cad.ATT.COM writes: >> ... You can use the lp >>spooler to take care of anything that you want to happen in a serially >>controlled manner. >Yup, and you could call it batch processing. While i agree that >there is probably a need for a tool like this in unix (here at >PSU there is a locally generated one called `batch') it strikes me >as funny to tout it as a feature of the unix spooler, considering >that unix was designed to be and stands out for being a highly interactive >environment. Don't laugh too hard .... one of the "major" line printer spoolers does exactly what he sugests ... MDQS from the nice folks at BRL. You can spool things to any sort of daemon, including a "shell" daemon. Multiple queues to any device, multiple devices hanging off a queue, and all sorts of nice features. It's just that when we put it up here, we ran into a number of bugs and are again running the ucb lpr stuff ... -- ----- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet ----- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET ----- ----- Je parle francais comme une vache espagnole.
michael@stb.UUCP (Michael) (09/11/87)
If you are having problems with a setuid program not being able to acess files, there is an old and working workaround: The set-G-id bit. Try this: chown bin lp; chgrp lp lp; chmod 02755 lp and chgrp lp /usr/spool/lpd; chmod g+w /usr/spool/lpd Then lpr can queue files in lpd, but still read files based on the owner permissions. Note: lpr is not the only program with this problem. See at, several games, and many others. Michael Gersten -- : Michael Gersten seismo!scgvaxd!stb!michael : Copy protection? Just say "Off site backup"
peter@sugar.UUCP (09/12/87)
That sounds like a joke, but it's for real. The only way the line printer daemon can read your file is if it has read permission on it, right? It's not running under your uid, right? Therefore some other uid has to be able to read the file, right? Note that I'm talking about the daemon, not the program "lp". Lp can, of course, spawn off a program to setuid(getuid()) and read the file. The line printer daemon can't. Basically, the only way around that would be to give lpd root privilege. This would be just asking for security problems (lp file, then rm the file and ln to the protected file you want to get into). Thus the requirement that the file be publicly readable is a security feature... at least you are the one to make it available and you (presumably) know what you're doing. The solution is to either "lp < file" or "lp -c file". The -c flag copies the file to the spool directory, which is better than catting them all to the printer 'cos you get the usual nice page breaks at the end of the file and all that stuff. If lp -c requires the file to be publicly readable, then that *is* a bug. But for plain lp it is, believe it or not, a feature. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)
peter@sugar.UUCP (09/12/87)
The problem with the various schemes that involve doing setuids and reading the files is that when you normally run lp... lp does not copy the file It just sticks the file name in the spool directory. Saves bundles of disk space. The only times it copies the file are: (a) The file is standard input, or (b) you specify the "-c" option on the command line. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)
allbery@ncoast.UUCP (Brandon Allbery) (09/12/87)
As quoted from <6410@brl-smoke.ARPA> by gwyn@brl-smoke.ARPA (Doug Gwyn ): +--------------- | In article <313@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: | I don't know much about System V "lp" (we use MDQS), but just because | the spooler is set-UID non-root does NOT necessarily imply a security | hole. System V is capable of switching back and forth between the real | UID and the effective UID as required; if the spooler is correctly +--------------- But lp doesn't use it, at least on Plexus sys3 (yes, it has the System V spooler) and Plexus sys5, both AT&T UNIX but neither of which has the uid swapping. -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> All opinions in this message are random characters produced when my cat jumped (-: up onto the keyboard of my PC. :-)
john@bradley.UUCP (09/13/87)
kitty.UUCP!Larry (Larry Lippman) Writes: |1. There is no reason why more than one printer name cannot be associated |with _one_ physical printer using _one_ physical I/O port. The usefulness |here is to invoke the _same_ printer in a different fashion merely by |specifying a different printer name as an lp(1) argument. For example, |one name will invoke a laser printer for landscape printing (132 cols wide), |with another name will invoke the laser printer for portrait printing (80 |cols wide). The different setup commands for the laser printer are contained |in the individual /usr/spool/lp/interface/printer_name shell scripts. I can think of one reason NOT to do just this....The lpsched program just checks to see if a job is currently printing on the named printer. It DOESN'T check to see if the physical port is busy. At least on SYSV 2.0, 2.1 --------------------- So if you haven't figured this one out....If you have two printers with different names (lp1 and lp2) connected to the same physical I/O port (tty11) then lpsched will print both jobs at once... I patched our lpsched program so that it will check to see if there are ANY printers busy which are connected to the same physical port as the requested printer. Other than that, I really like setting up printers this way.... vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv John Lengeling UUCP: {cepu,ihnp4,uiucdcs}!bradley!john Bradley University ARPA: cepu!bradley!john@CS.UCLA Text Processing PH: (309) 677-2230 Bradley Hall Room 6F Peoria, IL 61625
allbery@ncoast.UUCP (Brandon Allbery) (09/13/87)
As quoted from <2546@okstate.UUCP> by vasoll@a.cs.okstate.edu (Mark Vasoll): +--------------- | I've been reading about the various uses that people have dreamed | up for System V lp and thought I would contribute my own... | | I wrote an interface module that will open an outbound async port | (ala UUCP style) and execute a script controlled conversation with | whatever might be there (e.g. a "smart" modem, a data switch, etc., | in our case a Case Communications DCX 850) to establish a connection | to the destination printer, print the job, then return to the script | for any needed "disconnect" conversation (reseting the modem or whatever). +--------------- I can see it now -- AT&T sendmail: "lp -psmtp letter" ;-) -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> All opinions in this message are random characters produced when my cat jumped (-: up onto the keyboard of my PC. :-)
allbery@ncoast.UUCP (Brandon Allbery) (09/13/87)
As quoted from <319@pvab.UUCP> by robert@pvab.UUCP (Robert Claeson): +--------------- | Yeah, have it talk to Berkeley's 'lpd' daemon. Then it will be able to | spool things over the network to other hosts, communication servers | or printer servers too. +--------------- As if we needed an lpd. My print destination on ncoast is: job="$1" user="$2" title="$3" copies="$4" options="$5" shift; shift; shift; shift; shift exec uux - -r axcess!lp -t"$options" -n"$copies" -o"$options" "$@" Lpsched isn't the problem, it works fine. It's lp itself that is a bit stupid. -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> All opinions in this message are random characters produced when my cat jumped (-: up onto the keyboard of my PC. :-)
daryl@ihlpe.ATT.COM (Daryl Monge) (09/14/87)
In article <147@stb.UUCP>, michael@stb.UUCP (Michael) writes: > If you are having problems with a setuid program not being able to access files, > there is an old and working workaround: The set-G-id bit. I like this one, but it is not there yet. For example, I may have a test bed of source code or a data base that is owned by some project id and is set group read/world no access. My setGid application (lp or whatever) still cannot access the file since I am normally using my group permissions to access the file. My requirements on anyone offering a solution to this problem is that file access should follow normal UNIX file security semantics regardless of the set[UG]id-ness of the application. Daryl Monge UUCP: ...!ihnp4!ihcae!daryl AT&T CIS: 72717,65 Bell Labs, Naperville, Ill AT&T 312-979-3603
domo@riddle.UUCP (Dominic Dunlop) (09/15/87)
In article <147@stb.UUCP> michael@stb.UUCP (Michael Gersten) writes: >If you are having problems with a setuid program not being able to acess files, >there is an old and working workaround: The set-G-id bit. > >Try this: > chown bin lp; chgrp lp lp; chmod 02755 lp >and > chgrp lp /usr/spool/lpd; chmod g+w /usr/spool/lpd > >Then lpr can queue files in lpd, but still read files based on the owner >permissions. Er, sorry. In my experience, this doesn't work. I don't know what system Michael is using (as he references lpd, it probably isn't a vanilla System V.x port), but I have tried this work-around on a 3B2/400 running V.2, an NCR Tower XP running V.2, and a Compaq 386 running V.3. No soap. The problem is that programs in the lp suite create control and data files under /usr/spool/lp with 600 permissions for reasons of security. Consequently, unless all programs in the suite are setuid lp, they can't share the files correctly. I suppose you could fix this up if you had a source licence -- indeed, my reason for trying on three different systems was in the optimistic and vain hope that somebody had. For a program that correctly uses set-gid as a file security mechanism, see mail. Incidentally, it occurs to me that the only reason that lp < file gets around the problem is because of a security hole in the UNIX kernel. Were access rights checked on every read, rather than just when the file is opened, a setuid program would be unable to read a file with restricted permissions, even if it had been opened and attached to stdin by a shell which was able to read it. Are there implementations of *NIX out there (secure or networked versions, perhaps) where this work-around really does fail? Dominic Dunlop domo@riddle.uucp domo@sphinx.co.uk
metro@asi.UUCP (Metro T. Sauper) (09/16/87)
In article <15000001@bradley>, john@bradley.UUCP writes: > > kitty.UUCP!Larry (Larry Lippman) Writes: > > |1. There is no reason why more than one printer name cannot be associated > |with _one_ physical printer using _one_ physical I/O port. > | ..... > > I can think of one reason NOT to do just this....The lpsched program > just checks to see if a job is currently printing on the named printer. It > DOESN'T check to see if the physical port is busy. At least on SYSV 2.0, 2.1 > --------------------- > ........ > > John Lengeling UUCP: {cepu,ihnp4,uiucdcs}!bradley!john Funny, we do EXACTLY this (define to spooler printer to the SAME tty port). We don not have any problem what-so-ever with two spooled jobs printing at the same time. In fact, I got the impression that this was the way it was suppose to work. We use this feature to handle forms output to the printer. On our system we have LP1, LBLS2, LICS1, REN1, and WIDE1 all defined to the same printer. Normally only the one device is enabled which corresponds with the type of forms currently in the printer. In the case of WIDE1 however, we also enable LP1 which lets normal printed output print also. We have never had a conflict. -- Metro T. Sauper, Jr. Assessment Systems, Inc. Director, Remote Systems Development 210 South Fourth Street (215) 592-8900 ..!asi!metro Philadelphia, PA 19106
michael@stb.UUCP (09/17/87)
Aparently my earlier message didn't get out, so... There is a SIMPLE way to fix the problem with lp. Turn OFF the set-U-id bit. Turn on the set-G-id bit (chmod 2755 file). Make the group permission determine write ability to /usr/spool/lpd or whatever. PRESTO! Owner permission is used to access files by NAME, and security is given for access to the spooling directory. Michael -- : Michael Gersten seismo!scgvaxd!stb!michael : Copy protection? Just say "Off site backup"
rbp@investor.UUCP (Bob Peirce) (09/17/87)
> In article <193@sortac.UUCP> pls@sortac.UUCP (Pat Sullivan) writes: > > BTW, note that the orignal poster's problem can be solved (except for > the above) by simply specifying the "-c" switch to lp; this even handles > banners. Or you can specify the banner with the "-t" switch. (RTFM!) > -- > Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff Not on my system (Altos 3068/Unix V.2). The -c option just copies the file to the spool directory. Lp still must be able to read it. If it can't you get lp: can't access file "name". -- Bob Peirce, Pittsburgh, PA 412-471-5320 uucp: ...!{allegra, bellcore, cadre, idis, psuvax1}!pitt!investor!rbp NOTE: Mail must be < 30K bytes/message
tel@Ahab.UUCP (Tom Lowe) (09/18/87)
> > kitty.UUCP!Larry (Larry Lippman) Writes: > > |1. There is no reason why more than one printer name cannot be associated > |with _one_ physical printer using _one_ physical I/O port. The usefulness > |here is to invoke the _same_ printer in a different fashion merely by > |specifying a different printer name as an lp(1) argument. For example, > |one name will invoke a laser printer for landscape printing (132 cols wide), > |with another name will invoke the laser printer for portrait printing (80 > |cols wide). The different setup commands for the laser printer are contained > |in the individual /usr/spool/lp/interface/printer_name shell scripts. The interface program can be written to accept options using the -o option of lp.....i.e.: lp [options] -op # for printing portrait or lp [options] -ol # for printing landscape when lp calls the interface program, it would pass the -o options on to the interface program for it to interpret. The following is an example of how to interpret those options. -------- # Sample Spooler Interface # for spooling jobs to a laser printer # # bin=/usr/lbin lib=/usr/lib gid=`grep "^$2:" /etc/passwd | cut -f4 -d:` group=`grep "^[^:]*::$gid:" /etc/group | cut -f1 -d:` bname=$0 reqid=$1 usrid=$2 title=$3 copies=$4 options=$5 fname=$6 shift;shift;shift;shift;shift files="$*" # parse the spooler device dependent options # for i in $options do case "$i" in p) #do here what ever it is you have to do to #get the printer printing in portrait mode and print the stuff ;; l) #do here what ever it is you have to do to #get the printer to print in landscape mode and print the stuff esac done # the end. ------------ Notice: This is a very abbreviated interface program. It is designed to show how to use the options. If you have an imagen printer or access to the imagen interface program, take a look at it. All the code for stty settings and for the actual printing of the files has to be added. If you have any questions, send me a note! Tom Lowe lowe@psuvax1.UUCP
bob@its63b.ed.ac.uk (ERCF08 Bob Gray) (09/18/87)
In article <484@riddle.UUCP> domo@riddle.UUCP (Dominic Dunlop) writes: >Consequently, unless all programs in the suite are setuid lp, they can't >share the files correctly. I suppose you could fix this up if you had a >source licence -- indeed, my reason for trying on three different systems >was in the optimistic and vain hope that somebody had. > This problem has been fixed by GEC on our system 63s. The lp command switches back and forward between the real user id and the effective user id of lp. File ownerships are ajusted as needed, and care is taken that the real user id is used when checking the access permissions. The "fix" is not trivial and takes many tens of lines of code. Also, Re: batch processing. See the man page batch(1). a standard utility on system V.2. (actually a shell script calling "at -b"). Bob.
frank@wacsvax.OZ (Frank O'Connor) (09/22/87)
In article <313@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: >The System V print spooler runs as a SUID 'lp' command, which >means that the files I want to print must be readable by others or, >if I'm lucky, by the group. This implies that anyone on the system >will be able to print, copy or read the files ... I didn't like what it did either, and after persuading from other people in the department, I got in and CHANGED it. I know, you probably don't have the source code licence. Most of the changes involved changing the ownership and access permissions of the programs, and the lp spool directory hierarchy. There were only minor changes to the programs. First, I created a group called daemon, and made all the programs owned by group daemon, and most of the files in the spool directory. Specifically, the programs were changed as follows : /usr/bin/cancel 2755 lp daemon /usr/bin/disable 6750 lp daemon /usr/bin/enable 6750 lp daemon /usr/bin/lp 2755 lp daemon /usr/bin/lpstat 2755 lp daemon /usr/lib/accept 6750 lp daemon /usr/lib/lpadmin 6750 root daemon * /usr/lib/lpmove 6750 lp daemon /usr/lib/lpsched 6750 root daemon * /usr/lib/lpshut 6750 lp daemon /usr/lib/reject 6750 lp daemon And the files were all changed to owner 'lp', group 'daemon', mode 660 for files, and 770 for directories, with the exceptions of : .../lp/FIFO owned by root .../lp/SCHEDLOCK owned by root, mode 444 .../lp/log owned by root .../lp/oldlog owned by root .../lp/outputq owned by root .../lp/interface/lp0 mode 770 The changes to the code were to allow for the group being 'daemon', the owner of lpadmin and lpsched being 'root', and to change the default file creation modes to the above. I made changes to the makefile to reflect the above. The changes were not difficult once I had made up my mind that they should be done (it took a while to convince myself anyone would release a system with such an obvious bug!). There are no security loopholes that I know of. 'lp' still checks for permission to be able to print the file, and therefore lpsched doesn't need to. Users can't write to the spool directory, or read files in it, so security of the spool files are maintained. I hope this helps. I am surprised noone else has done it. I am a long way from being a Unix guru. I would be interested in any comments. etc.
demasi@paisano.UUCP (Michael C. De Masi) (09/24/87)
In article <484@riddle.UUCP>, domo@riddle.UUCP (Dominic Dunlop) writes: ... > > Incidentally, it occurs to me that the only reason that > > lp < file > > gets around the problem is because of a security hole in the UNIX kernel. > Were access rights checked on every read, rather than just when the file is > opened, a setuid program would be unable to read a file with restricted > permissions, even if it had been opened and attached to stdin by a shell > which was able to read it. ... > Dominic Dunlop > domo@riddle.uucp domo@sphinx.co.uk How can this be considered a security hole? When redirecting standard input from a file into a program, setuig-gid or not, one still has to have the proper permissions to read the file that's being redirected. That is, if you can't read the file, you can't redirect it as input to another program, anyway, so what's the problem? If I'm reading what you wrote correctly, every utility within UNIX would have to have the same ownership (effectively) as every file on which it is to work. You can't mean that, can you? By the same token, what you say is true, permissions are only checked at the time a file is opened. But all that amounts to is that if you are reading from (or writing to) one of my files, and within the course of your process I change the permissions on that file in such a way as to make it inaccessable to you, it will have no effect on your process (unless you close the file, for some rea- son, then try to re-open it) but again, what's the big deal? If you wish to maintain a file with restricted access, create it that way. As I said, perhaps I misunderstand you, if so, please point out my error (Nothing like a good argument, huh?) -- Michael C. De Masi - AT&T Communications (For whom I work and not speak) 3702 Pender Drive, Fairfax, Virginia 22030 Phone: 703-246-9555 UUCP: seismo!decuac!grebyn!paisano!demasi "There are monkey boys on the premises." Unknown red Lectroid.