Re: Diskless print server

[Jim Hague <hague@research.canon.com.au>]

(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