garvey@cmic.UUCP (Joe Garvey) (07/04/90)
Try the following:
$ su lp
$ lp /etc/motd
It will fail under HP-UX 7.0. Lp (the user) can't submit print jobs. Actually
that's not true. Lp can submit a print job, it will just error out when
execution is attempted.
Does anyone know how this wonderful state of affairs occurred? Is there
a work around?
This is annoying if you are doing lp maint. This is a real problem if
you create remote printer model scripts that simply use features of existing
model scripts. (-oraw, -o2 (two sided printing)).
For example... to provide "hpgl" access to a laserprinter for graphics from
PC programs, a model script for the hpgl_lp device might contain:
hpgl2pcl | lp -oraw -dlp2
This example has a special program (hpgl2pcl) convert an hpgl file to pcl,
and resubmit it for printing on the actual laserprinter using the -oraw option.
What's even more confusing is /usr/bin/lp is suid root! Root should be able
to do what ever root wants.
Could this be a bug in lp?
PS. I just updated to 7.0. I can understand what all the hollering
is(was) about. This has been the toughest release since the 5.0
installation (where I started). It's time to discuss customer site beta
testing with HP again. It had nice sexy windows though. :-)
PPS. Did anyone else notice that /etc/update said 86/91 filesets were
installed for the standard bundle (300 series)? Very careful checking
of the update log and the filesets by myself and HP has verified 91
filesets were installed. But the update (and customization) only showed
86. If you noticed this, I need to correspond with you. Please.
--
Joe Garvey UUCP: {apple,backbone}!versatc!mips!cmic!garvey
California Microwave Internet: garvey%cmic@mips.com
990 Almanor Ave HP Desk: garvey (cmic@mips.com) / hp1900/ux
Sunnyvale, Ca, 94086 800-831-3104 (outside CA)
408-720-6439 (let it ring) 800-824-7814 (inside CA)jp@hplb.hpl.hp.com (Julian Perry) (07/05/90)
In article <360@cmic.UUCP>, garvey@cmic.UUCP (Joe Garvey) writes: |> Try the following: |> |> $ su lp |> $ lp /etc/motd |> |> It will fail under HP-UX 7.0. Lp (the user) can't submit print jobs. Actually |> that's not true. Lp can submit a print job, it will just error out when |> execution is attempted. |> |> Does anyone know how this wonderful state of affairs occurred? Is there |> a work around? Yep - it's a known bug. A workaround is to do the following: cpset /usr/bin/lp /usr/spool/lp/lp.bin 4555 lp bin and when logged in as lp use the /usr/spool/lp/lp.bin binary rather than the /usr/bin/lp version. Fixed versions of the /usr/bin/lp binary may be available - contact your SE. |> What's even more confusing is /usr/bin/lp is suid root! Root should be able |> to do what ever root wants. It happens because lp gets confused as to who it should be at any given point (it does some uid hopping to make files have the right permissions etc) and tries the wrong things as the wrong uid! I believe it's fixed for the next release. Jules -- E-MAIL: jp@hplb.hpl.hp.com || jp@hpl.hp.co.uk IN-REAL-LIFE: Julian Perry ORGANISATION: Hewlett-Packard Laboratories, Bristol ADDRESS: Filton Road, Stoke Gifford, Bristol, England, BS12 6QZ TELEPHONE: +44 272 799910 x 24019
krishnan@uceng.UC.EDU (Ramaswamy Krishnan) (07/05/90)
In article <360@cmic.UUCP> garvey@cmic.UUCP (Joe Garvey) writes: >Try the following: > >$ su lp >$ lp /etc/motd > >It will fail under HP-UX 7.0. Lp (the user) can't submit print jobs. Actually >that's not true. Lp can submit a print job, it will just error out when >execution is attempted. > >Does anyone know how this wonderful state of affairs occurred? Is there >a work around? We found this problem as soon we upgraded to 7.0 - and I posted it here and of course, our call to HP support is yet to be answered satisfactorily. It seems that when user lp execs lp command, the Cf file created is owned by root - which user lp does not have the privilege to lock and so it fails. Did we find a fast dumb hack? Yes - I had to make the print queue that was calling lp to remote print to my own system! Good for once to not know oneself ;-) -- Ramaswamy Krishnan Krishnan@UC.EDU (ARPA) College of Engineering uceng!krishnan (UUCP) Univ. of Cincinnati (513) 556-4770
lienhart@hpfcdc.HP.COM (Bob Lienhart) (07/06/90)
The following workaround should bring lp functionality back closer to 6.5. chown lp /usr/bin/lp chgrp bin /usr/bin/lp chmod 6555 /usr/bin/lp ll /usr/bin/lp should appear as follows: -r-sr-sr-x 1 lp bin 94208 Nov 22 1989 /usr/bin/lp This should have minimal impact on your spooling. The internal changes were to allow printing of files that you could read but did not own. This will of course break this added functionality in 7.0. But the impact should be minimal. This defect has been fixed in 8.0. Bob Lienhart