Bug 49908 - uucp no longae work (because it cannot write to /var/lock)
Summary: uucp no longae work (because it cannot write to /var/lock)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: uucp
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-24 23:57 UTC by greg hosler
Modified: 2007-04-18 16:35 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2001-08-16 13:48:39 UTC

Attachments (Terms of Use)

Description greg hosler 2001-07-24 23:57:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.3-2.9.2smp i686)

Description of problem:
uucp depends upon being able to write lock/pid files to /var/lock - in
order to accomodate this, /var/lock is set perms 775, owned by uucp, and
the limited uucp
utilities (uucico) that require write permission are set SGID uucp.

as of Fairfax, /var/lock has been changed to 755, root.root - under this
permissions scheme, uucp will no longer work.

How reproducible:

Steps to Reproduce:
1.set up a uucp server on another machine
2. do: uucico -S <that server tag>
3. observe the error message in /var/log/uucp/Log

Actual Results:  uucico aborts without so much as dialing the number
because it cannot write to

Expected Results:  uucico to work, as before this change

Additional info:

see bug 49818 - it appears that this is intentional, which is to say that
RH intends for
uucp to not work. If this is really really true, then you should remove
uucp from the distribution, or come up with a different way to coordinate
common access to the serial ports.

Comment 1 greg hosler 2001-08-01 15:28:26 UTC
Problem also exists in Beta 3 (roswell) - when uucico -S <uucp host> is issued,
following is written to /var/messages:

	uucico lugs-server - (2001-07-31 22:32:23.95 1751) ERROR: creat
(/var/lock/TMP00000006d7): Permission denied

The reason is because /var/log is 755 root.root, and uucp (and all serial
programs) are expecting
it to be 775 root.uucp

I have written a history of serial support in Unix, you will find it in the


Comment 2 Nils Philippsen 2001-08-16 06:12:53 UTC
This is still the case, even with the latest changes to /var/lock in the
filesystem. At the moment, I have to open up /var/lock completely in order
for uucp to work (which is even worse than group-writable IMO).

Comment 3 greg hosler 2001-08-16 12:24:26 UTC
> This is still the case, even with the latest changes to /var/lock in the
> filesystem. At the moment, I have to open up /var/lock completely in order
> for uucp to work (which is even worse than group-writable IMO).

That is NOT TRUE. If you were at all familiar w/ uucp, you would KNOW this
to be NOT TRUE.

In order for UUCP to work, permissions of 775, and ownership of root.uucp
is perfectly adequate. It is, afterall, how it used to be set, and is, infact
by design.

If you move the lock directory to (for example), /var/lock/serial (or
/var/lock/uucp), you need only set that particular directory as 775, root.uucp,
and you can leave /var/lock 755 root.root

Note that that would be non-compliant with FHS 2.2

Note also that your current scheme of a hierarchy within /var/lock is itself
non-compliant with FHS 2.2 (the proper place for those directories would be
within /var/lib - see section 5.8 of the FHS 2.2 - While I do not expect you
to swap the stuff in /var/lock that should NOT be there (the sub directory
hierarchy, as well as console.lock), I do think that you should give serious
consideration to moving this stuff to /var/lib (where, in compliance with FHS, 
it belongs) in RH 8.0


Comment 4 Nils Philippsen 2001-08-16 12:47:07 UTC
Ahem, you seem to have misunderstood me completely. First: I'm not the owner of
the uucp package and second this messages was a hint to jbj (the owner) that a
recent change in a non-public release of the filesystem package didn't solve the
problem either -- in fact it made it worse (I don't know whether I may
disclose the details to you, so I leave it that way). I presume that there need
to be some changes in the uucp package to work smoothly with the change in
And last: I am indeed familiar with UUCP, as my private mails depend on
it working, thank you very much. I don't think that bugzilla is a place for ad
hominem attacks.

Comment 5 Nils Philippsen 2001-08-16 12:49:27 UTC
Ugh, strike jbj as the owner, set havill in the last comment. It's way too hot
to think clearly ATM.

Comment 6 Jeff Johnson 2001-08-16 12:51:27 UTC
The /var/lock directory is now root.lock 775. What remains
for uucp is to use lockdev to create the device lock and
check that uucp needs no other locks in /var/lock. There
might still be a system lock created in /var/lock, hard to
from just reading sources.

Comment 7 Jeff Johnson 2001-08-16 13:01:58 UTC
Nils: Can you do
	chgrp uucp /usr/sbin/lockdev /var/lock
	chmod g+s /usr/sbin/lockdev
and verify two things
	1) Does uucp/minicom work with that scheme?
	2) Are there any other uucp locks beside the device
	lock in /var/lock?
If yeas and no are the answers, I can get uucp fixed pretty
quickly. The above scheme should also provide a better
alternative to "chmod 777 /var/lock" and is nearly as
secure as the desired root.lock ownership.

Comment 8 Nils Philippsen 2001-08-16 13:23:30 UTC
- uucp does work that way, the only lock is LCK..${peername} (I do UUCP over
- minicom works, the lock files are:
  LCK...31613  LCK..ttyS0  LCK.004.064
  -- apparently PID, device and something I don't recognize

Comment 9 Jeff Johnson 2001-08-16 13:48:34 UTC
OK, I know what to do now. The LCK..${peername} is destined
for /var/lock/uucp uucp.uucp 775, while the device lock
will use lockdev in /var/lock.

The other lock is major.minor IIRC. Thanks for the help.

Comment 10 Jeff Johnson 2001-08-30 15:37:26 UTC
Fixed (but not yet verified) in uucp-1.06.1-29 and later. Changes there
    1) move uucp per-peer lock from /var/lock to 775 uucp.uucp
    /var/lock/uucp sub-directory.
    2) use setgid lock helper /var/sbin/lockdev to create per-device
    lock file(s) in root.lock 775 /var/lock directory.
Look for a uuxqt exploit fix in uucp-1.06.1-30 as well.

Note You need to log in before you can comment on or make changes to this bug.