Bug 12912

Summary:

[PATCH] lpd leaves lock file permissions afoul

Product:

Base System

Reporter:

jedgar <jedgar>

Component:

bin

Assignee:

freebsd-bugs (Nobody) <bugs>

Status:

Closed FIXED

Severity:

Affects Only Me

Priority:

Normal

Version:

3.2-STABLE

Hardware:

Any

OS:

Any

Attachments:

Description	Flags
file.diff	none

Description jedgar 1999-08-01 20:40:00 UTC

	When using a custom definition in /etc/printcap (for a remote printer in my case,
	modeled of the example therein) and the lock file does not exist, lpd leaves 
	permissions on the lock file as follows:

		-------rwx   1 root     daemon         22 Aug  1 15:16 lock

	which leave the printer disabled until the permissions are fixed.  If the lock
	file exists, permissions are left as normal:

		-rw-rw-r--   1 root     daemon         22 Aug  1 15:20 lock

	In addition, the lock file file-descriptor (lfd) is never closed.

Fix: Either create the lock file (though shouldn't be necessary), or apply the
	following patch.
How-To-Repeat: 
	Create a custom /etc/printcap entry:

	lp|sol printer:\
		:sh:\
		:mx#0:\
		:rm=sol:sd=/var/spool/output/sol:lf=/var/log/lpd-errs:

	create the spool directory, but do not create the lock file itself. After
	restarting lpd and printing something, the lock file's permissions will be
	left as 0007.

Comment 1 jedgar 1999-11-19 02:35:14 UTC

This problem doesn't seem to be reproducible using 3.3-RELEASE/-STABLE or
4.0-CURRENT...feel free to close.

-----
Chris D. Faulhaber               |  You can ISO9001 certify the process of 
System/Network Administrator,    |  shooting yourself in the foot, so long
Reality Check Information, Inc.  |  as the process is documented and reliably
<jedgar@fxp.org>                 |  produces the proper result.

Comment 2 cpiazza freebsd_committer

1999-12-15 23:04:20 UTC

State Changed
From-To: open->closed

Originator reports that the problem can't be reproduced on 3.3/4.0