From nobody@FreeBSD.org  Fri Feb 17 09:24:31 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D883616A422
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 17 Feb 2006 09:24:31 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 6B75843D5F
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 17 Feb 2006 09:24:27 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k1H9OQqS009114
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 17 Feb 2006 09:24:26 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k1H9OQh8009113;
	Fri, 17 Feb 2006 09:24:26 GMT
	(envelope-from nobody)
Message-Id: <200602170924.k1H9OQh8009113@www.freebsd.org>
Date: Fri, 17 Feb 2006 09:24:26 GMT
From: Michael Szklarski <dysoft@kco.com.pl>
To: freebsd-gnats-submit@FreeBSD.org
Subject: uninitialised struct stat in lpd prevents it from normal operation
X-Send-Pr-Version: www-2.3

>Number:         93469
>Category:       amd64
>Synopsis:       uninitialised struct stat in lpd prevents it from normal operation
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gad
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Feb 17 09:30:04 GMT 2006
>Closed-Date:    Mon Jul 17 21:13:05 GMT 2006
>Last-Modified:  Mon Jul 17 21:13:05 GMT 2006
>Originator:     Michael Szklarski
>Release:        6.0
>Organization:
ABG Ster-Projekt
>Environment:
FreeBSD Tygrytron 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Sat Feb 11 00:30:29 CET 
2006     msz@Tygrytron:/usr/src/sys/amd64/compile/Tygrytron  amd64
>Description:
Already reported in:
http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64/93413
now I have traced down the problem:

After first-time installation of spool directories, 
e.g. /var/spool/lpd/rattan , as seen in the Handbook, these directories are 
of course empty.

Running first time printout is successful, lpd creates "lock" file in the 
spool directory, but it has following (strange) attributes:

---xrwS--T  1 root  daemon  20 Feb 16 01:03 lock

Unfortunately, running printout for the next time does not work - lpr queues 
the job and nothing happens ! It is due to a sw-bug 
in /usr/src/usr.sbin/lpr/lpd/printjob.c, in function void printjob(struct 
printer* pp); i.e. look at the following lines of code:

[203]		 if (stat(pp->lock_file, &stb) == 0 && (stb.st_mode & LFM_PRINT_DIS))
		 		 		 exit(0);

Seems OK, but if NO LOCK FILE EXIST, "stb" remains uninitialized ! 
Unfortunately, this sets "+x" attribute, which is defined elsewhere
as
#define		 LFM_PRINT_DIS		 (S_IXUSR)
and it results in executing exit(0) in the line mentioned above, but only for 
the second time.

Further in the code one can find fchmod(lfd,stb.st_mode), which uses 
uninitialised "stb".
>How-To-Repeat:
kill lpd.
remove spool directories.
recreate spool directories.
run lpd.
try to print twice (or more).
>Fix:
/usr/src/usr.sbin/lpr/lpd/printjob.c: function void printjob(struct printer* 
pp), line 203: replace those 2 lines mentioned above with:

		 if (stat(pp->lock_file, &stb) == 0)
		 {
		 		 if (stb.st_mode & LFM_PRINT_DIS)
		 		 {
		 		 		 exit(0);		 		 /* printing disabled */
		 		 }
		 } else
		 {
		 		 stb.st_mode = LOCK_FILE_MODE;
		 }

rebuild and install lpd. Works for me.

Workaround:

create lock files after creating spool directories:

 mkdir /var/spool/lpd/rattan
 touch /var/spool/lpd/rattan/lock

and/or change attributes of lock file:

 chmod 664 /var/spool/lpd/rattan/lock
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-amd64->gad 
Responsible-Changed-By: arved 
Responsible-Changed-When: Thu Jul 6 12:15:31 UTC 2006 
Responsible-Changed-Why:  
over to lpr maintainer 

http://www.freebsd.org/cgi/query-pr.cgi?pr=93469 

From: Garance A Drosehn <gad@FreeBSD.org>
To: bug-followup@FreeBSD.org, dysoft@kco.com.pl
Cc:  
Subject: Re: amd64/93469: uninitialised struct stat in lpd prevents it from normal operation
Date: Thu, 6 Jul 2006 15:22:58 -0400

 I have a slightly different fix for this, which I have
 been running with (here at RPI) for awhile now.  I
 always wondered why no one else had noticed this
 problem.  I guess it's just that when most people do
 notice it, they just fix the permissions without ever
 figuring out why the permissions were wrong to start
 with.
 
 Thanks for the report.
 
 -- 
 Garance Alistair Drosehn     =      gad@gilead.netel.rpi.edu
 Senior Systems Programmer               or   gad@FreeBSD.org
 Rensselaer Polytechnic Institute;             Troy, NY;  USA
 
State-Changed-From-To: open->closed 
State-Changed-By: gad 
State-Changed-When: Mon Jul 17 21:11:22 UTC 2006 
State-Changed-Why:  
I have committed the change to lpd/printjob.c which should fix this 
problem.  The change had been in 7.x-current for a week without any 
apparent problems. 

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