Hard for me to explain this but... Problem is with /var/spool/lpd/*/cf* control files. If file is printed locally (via lpr), cf* file is created with right permissions: ls -l => -rw-rw---- 1 daemon daemon ... cf*. But if file is printed remotely and cf* are creates by lpd, cf* files have bad permissions: ls -l => -rw-rw---- 1 root daemon ... cf*. It has bad impact on print filters ("if" in printcap) which extract some information from cf* control files. Filters are executed with these ids: uid=1 (daemon) gid=0 (wheel). They do not belong to wheel group. (Line "daemon:*:1:daemon" in /etc/group doesn't help!) So if file is received via network, print filter hasn't permissions for reading control files. (Patch changes root => daemon.) Fix: Here is my simple patch for FreeBSD 2.2.7-STABLE: ("$Id: recvjob.c,v 1.5.2.3 1997/10/06 04:21:33 imp Exp $";) (In FreeBSD 3.0-CURRENT it is very similar - only lines 106-107 are unnecessary.)
Rudolf Cejka wrote: > Problem is with /var/spool/lpd/*/cf* control files. If file is > printed locally (via lpr), cf* file is created with right > permissions: > ls -l => -rw-rw---- 1 daemon daemon ... cf*. > But if file is printed remotely and cf* are creates by lpd, > cf* files have bad permissions: > ls -l => -rw-rw---- 1 root daemon ... cf*. > > It has bad impact on print filters ("if" in printcap) which > extract some information from cf* control files. Filters > are executed with these ids: uid=1 (daemon) gid=0 (wheel). > They do not belong to wheel group. I understand the issue you are talking about, but I would argue that print filters have no business reading the control files. The control files are "a protocol" of sorts for an lpr process (or some other lpd process) to communicate with an lpd process. Imagine what happens if we want to change the format of cf files, which we may very well want to do (if we accept jobs from via protocols other than lpd). I don't think print filters should have any idea of the format of cf files. So, my question to you is, What is the exact information that your print filters need from the cf-files? For your print filters, would it be better if they picked up that information (whatever you need) via some environment variables that lpd might set before starting up your filter? This is the solution I would prefer to implement. -- --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
This PR bin/7973 was originated 2 years ago and I have somewhat different point of view on this problem now, so: Garance A Drosihn wrote (2000/11/02): > I understand the issue you are talking about, but I would argue > that print filters have no business reading the control files. > The control files are "a protocol" of sorts for an lpr process > (or some other lpd process) to communicate with an lpd process. Yes, I agree. > Imagine what happens if we want to change the format of cf > files, which we may very well want to do (if we accept jobs > from via protocols other than lpd). I don't think print > filters should have any idea of the format of cf files. I think we do not want to change the format of control files because there is RFC 1179: Line Printer Daemon Protocol. However, if we want to accept jobs from other protocols, control files can have another format and you are right that the problem would be back. > So, my question to you is, What is the exact information that > your print filters need from the cf-files? For your print The motivation for my patch was because of apsfilter-5.x.x. It reads control files and acquires host name, user name a job name. On-coming apsfilter-6.x.x gets all this information from command line parameters, where current lpr implementation offers user name (-n) and host name (-h) only. Job name is missing. The main author of apsfilter is Andreas Klemm (andreas@FreeBSD.ORG), so maybe we may talk with him too (... CCed to him). > filters, would it be better if they picked up that information > (whatever you need) via some environment variables that lpd > might set before starting up your filter? Environment variables or command line parameters. We have -n and -h already there, so the only missing parameter is job name (LPRng has -f). If we look at LPRng further, it has another very interesting parameter: -Z z_opts, where z_opts are random parameters from user passed directly to print filters. > This is the solution I would prefer to implement. Me too. How much of free time do you have (and possibly others, if any) for work on FreBSD's lpr subsystem? Thanks. -- Rudolf Cejka (cejkar@dcse.fee.vutbr.cz; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic
Responsible Changed From-To: freebsd-bugs->gad I will provide an alternate method of getting the necessary info from lpd.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped