Re: Diskless print server

[Heinrich Rebehn <rebehn@comm.uni-bremen.de>]

Jim Hague wrote:
> 
> (SLUGgers - Charlie thought this from the netboot list might be of interest).
> 
> Me:
> >> I've recently acquired an old 386 diskless box I'm booting with Etherboot
> >> into RH4.2 off a RH4.2 host. / is mounted via NFS from a client specific
> >> directory on the host. /usr is mounted ro directly from the host /usr, and
> >> /home is mounted rw directly from the host /home. I have not applied the
> >> swap via NFS patches, so there's no swap.
> >>
> >> After customising /etc and /var, everything seems to be working OK. I've
> >> even configured XFree86 (slowww.....).
> >>
> >> Well, almost everything. Printing doesn't work, which is a bit of a bugger
> >> as I want to use it as a print server. The printer is configured correctly,
> >> the spool directory exists with correct permissions, print jobs get spooled
> >> into it, and the print jobs are picked up by lpd and the input filter (if)
> >> is activated. At which point it all goes pear-shaped; when the filter tries
> >> to read stdin, the read fails and 'file: - no read permission' (or similar)
> >> appears on the console.
> 
> Heinrich:
> >I have had a similar problem with printing on a diskless machine using
> >PLP (Public Line Printer). The error message eas the same, although it
> >occured in an earlier stage - when lpd was trying to read the control
> >file on /tmp.
> >The reason was, that lpd did some filecopying like:
> >
> >       become user1
> >       open source
> >       become user2
> >       open dest
> >       copy source to dest
> >
> >The error occured when lpd tried to read source as user2. This does not
> >seem to be a problem on local filesystems, but does not work on NFS,
> >obviously NFS checks permission on every access, while on local fs only
> >the 'open' is checked.
> >Since we don't have elevated security needs, i simply deleted the
> >'become userx' stuff from the plp sources.
> >I did this about a year ago, and i tried to recall from memory what i
> >did, so the details may differ, but the basic behaviour was the same.
> 
> Thanks for the suggestion. As it happens, I did some further investigation
> last night, and as usually happens when I ask a question in public, the act
> of asking the questions does something to my head which promptly spots the
> problem.....
> 
> You're right. What seems to be happening in this case is this:
> 
> 1. lpr copies file to spool dir. Control file is owner 'bin', group 'lp'.
>    Data file is owned by the user who submitted the job, group 'lp'.
> 
> 2. lpd comes along, finds the job, reads the control file, opens the
>    data file, setuid's to 'bin' and execs the filter with the data file
>    as stdin. This works fine on a local file system. But reading stdin
>    with NFS sends the UID and GID for verification; 'bin' group 'root'
>    (the filter) doesn't have permission to read the data file, so BOOM!
> 
> This morning I grabbed the latest lpr source RPM from the local RedHat
> mirror (0.21-2). According to the logs, this was modified on 27/10/97; it's
> what is distributed in RH5.0. The code now setuid's to the uid of the user
> who submitted the job before running the filter, so should work. I'll try
> it and report back.
> --
> Jim Hague - hague@research.canon.com.au(Work),bears@cix.co.uk(Play)
> Canon Information Systems Research Australia        +61 2 9805 2854

What brand of lpr are you using ? PLP ? LPReng ? I am asking because i
want to switch to LPReng <http://www.astart.com/LPRng.html> and want to
make sure i don't run into the same problems.

Regards

Heinrich Rebehn

University of Bremen
Physics / Electrical and Electronics Engineering
- Department of Telecommunications -

E-mail: mailto:rebehn@comm.uni-bremen.de
Phone : +49/421/218-4664
Fax   :            -3341