bin/74418: lpd creates lock file with bad permissions under remote LPR

Ted Mittelstaedt tedm at
Fri Nov 26 08:00:57 PST 2004

>Number:         74418
>Category:       bin
>Synopsis:       lpd creates lock file with bad permissions under remote LPR
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 26 16:00:56 GMT 2004
>Originator:     Ted Mittelstaedt
>Release:        FreeBSD 4.9-RELEASE i386
System: FreeBSD 4.9-RELEASE FreeBSD 4.9-RELEASE #3: Fri Dec 5 00:52:56 PST 2003 tedm at i386


When a brand new print queue is defined for lpd, (ie: /var/spool/output/new-lp)
it does not contain a .seq, lock or status file.  These files are automatically
created by the lpd daemon when it gets it's first job and are reused by
subsequent jobs.

If the job originates locally, the files are created as follows:

-rw-r----x  1 root  daemon    4 Nov 26 07:39 .seq
-rw-rw-r--  1 root  daemon   30 Nov 26 07:40 lock
-rw-rw-r--  1 root  daemon   24 Nov 26 07:40 status

If the job is a remote job that is sent via the lpr protocol to the system,
the lock file is created as such:

------xr--  1 root  daemon   30 Nov 26 07:41 lock

Because lpd cannot modify the lock file this stops future jobs to the

If permissions are manually modified to the lock file,  chmod 664, 
then everything works fine.  The problem will not recurr unless the
lock file is manually deleted and recreated by lpd with a lpr job.

The remote system sending to the FreeBSD system in this case was a
Solaris 2.5.1 system, I don't know if that has any bearing on it or


workaround is when creating a new queue, to run a local job through it
first.  Or fix the lock file permissions manually.



More information about the freebsd-bugs mailing list