From cejkar@dcse.fee.vutbr.cz  Fri Sep 18 06:33:55 1998
Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA25508
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 18 Sep 1998 06:33:53 -0700 (PDT)
          (envelope-from cejkar@dcse.fee.vutbr.cz)
Received: from kazi.dcse.fee.vutbr.cz (kazi.dcse.fee.vutbr.cz [147.229.8.12])
	by boco.fee.vutbr.cz (8.9.1/8.9.1) with ESMTP id PAA07414
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 18 Sep 1998 15:33:19 +0200 (MET DST)
Received: (from cejkar@localhost)
	by kazi.dcse.fee.vutbr.cz (8.8.8/8.8.8) id PAA04924;
	Fri, 18 Sep 1998 15:33:18 +0200 (CEST)
Message-Id: <199809181333.PAA04924@kazi.dcse.fee.vutbr.cz>
Date: Fri, 18 Sep 1998 15:33:18 +0200 (CEST)
From: cejkar@dcse.fee.vutbr.cz
Reply-To: cejkar@dcse.fee.vutbr.cz
To: FreeBSD-gnats-submit@freebsd.org
Subject: lpd: Bad control file owner in case of remote printing
X-Send-Pr-Version: 3.2

>Number:         7973
>Category:       bin
>Synopsis:       lpd(8) Bad control file owner in case of remote printing
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    gad
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 18 11:20:02 PDT 1998
>Closed-Date:    
>Last-Modified:  Wed May 21 20:36:12 UTC 2008
>Originator:     Rudolf Cejka
>Release:        FreeBSD 2.2.7-STABLE, FreeBSD 3.0-CURRENT i386
>Organization:
FEE TU Brno, Czech Republic
>Environment:

	Originally found in FreeBSD 2.2.7-STABLE, but FreeBSD 3.0-CURRENT
	has the same problem.

>Description:

	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.)

>How-To-Repeat:
>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.)

*** recvjob.c.bad	Fri Sep 18 13:33:13 1998
--- recvjob.c	Fri Sep 18 14:41:14 1998
***************
*** 79,85 ****
  static int        noresponse __P((void));
  static void       rcleanup __P((int));
  static int        read_number __P((char *));
! static int        readfile __P((char *, int));
  static int        readjob __P((void));
  
  
--- 79,85 ----
  static int        noresponse __P((void));
  static void       rcleanup __P((int));
  static int        read_number __P((char *));
! static int        readfile __P((char *, int, int));
  static int        readjob __P((void));
  
  
***************
*** 103,108 ****
--- 103,110 ----
  		LF = _PATH_CONSOLE;
  	if (cgetstr(bp, "sd", &SD) == -1)
  		SD = _PATH_DEFSPOOL;
+ 	if (cgetnum(bp, "du", &DU) < 0)
+ 		DU = DEFUID;
  	if (cgetstr(bp, "lo", &LO) == -1)
  		LO = DEFLOCK;
  
***************
*** 188,194 ****
  				(void) write(1, "\2", 1);
  				continue;
  			}
! 			if (!readfile(tfname, size)) {
  				rcleanup(0);
  				continue;
  			}
--- 190,196 ----
  				(void) write(1, "\2", 1);
  				continue;
  			}
! 			if (!readfile(tfname, size, 1)) {
  				rcleanup(0);
  				continue;
  			}
***************
*** 214,220 ****
  			if (strchr(dfname, '/'))
  				frecverr("readjob: %s: illegal path name",
  					dfname);
! 			(void) readfile(dfname, size);
  			continue;
  		}
  		frecverr("protocol screwup: %s", line);
--- 216,222 ----
  			if (strchr(dfname, '/'))
  				frecverr("readjob: %s: illegal path name",
  					dfname);
! 			(void) readfile(dfname, size, 0);
  			continue;
  		}
  		frecverr("protocol screwup: %s", line);
***************
*** 225,233 ****
   * Read files send by lpd and copy them to the spooling directory.
   */
  static int
! readfile(file, size)
  	char *file;
  	int size;
  {
  	register char *cp;
  	char buf[BUFSIZ];
--- 227,236 ----
   * Read files send by lpd and copy them to the spooling directory.
   */
  static int
! readfile(file, size, grant)
  	char *file;
  	int size;
+ 	int grant;
  {
  	register char *cp;
  	char buf[BUFSIZ];
***************
*** 237,242 ****
--- 240,247 ----
  	fd = open(file, O_CREAT|O_EXCL|O_WRONLY, FILMOD);
  	if (fd < 0)
  		frecverr("readfile: %s: illegal path name: %m", file);
+ 	if (grant)
+ 		(void) fchown(fd, DU, -1); /* owned by daemon for protection */
  	ack();
  	err = 0;
  	for (i = 0; i < size; i += BUFSIZ) {
>Release-Note:
>Audit-Trail:

From: Garance A Drosihn <drosih@rpi.edu>
To: freebsd-gnats-submit@FreeBSD.org
Cc: cejkar@dcse.fee.vutbr.cz
Subject: Re: bin/7973: lpd: Bad control file owner in case of remote
 printing
Date: Thu, 2 Nov 2000 23:55:11 -0500

 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
 

From: Cejka Rudolf <cejkar@dcse.fee.vutbr.cz>
To: Garance A Drosihn <drosih@rpi.edu>
Cc: freebsd-gnats-submit@FreeBSD.org, andreas@FreeBSD.org
Subject: Re: bin/7973: lpd: Bad control file owner in case of remote printing
Date: Fri, 3 Nov 2000 12:10:32 +0100

 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 
Responsible-Changed-By: gad 
Responsible-Changed-When: Wed Dec 27 09:42:04 PST 2000 
Responsible-Changed-Why:  
I will provide an alternate method of getting the necessary info from lpd. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=7973 
>Unformatted:
