Bug 58807

Summary:	Ownership problem of /var/lock and non-use of /var/lock/uucp
Product:	[Retired] Red Hat Linux	Reporter:	Nick Craig-Wood <ncw>
Component:	mgetty	Assignee:	Jason Vas Dias <jvdias>
Status:	CLOSED CURRENTRELEASE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	pvrabec, twoerner
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-06-14 21:02:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nick Craig-Wood 2002-01-24 22:35:32 UTC

Description of Problem:

Traditionally anyone who is a member of the uucp group can access the serial
ports.  Hence /dev/ttyS* is group owned by uucp.  To use the serial ports it is
necessary to create lock files.  These are traditionally created in /var/lock,
HOWEVER, /var/lock is now group owned by lock not uucp so non root programs
can't create proper locks.

HOWEVER there is a /var/lock/uucp which *is* group owned by uucp, BUT the serial
using program I tested (mgetty and I think pppd) are making their locks in
/var/lock not /var/lock/uucp.

There seems to be some confusion over the status of /var/lock and /var/lock/uucp
and inconsistent usage.

This confusion has broken our application unfortunately because it is run as a
user with group membership of uucp and it can't create locks any more.

How Reproducible:

Steps to Reproduce:
1. ls -la /var/lock
2. note that is is group owned by lock
3. note the presence of a /var/lock/uucp directory group owned by uucp
4. start mgetty/pppd and note them putting their locks in /var/lock

Comment 1 Jeff Johnson 2002-02-01 21:57:58 UTC

Yup, the "traditional" uucp ownership scheme has changed
slightly between 7.[01] and 7.2 in order to become more
FHS compliant.

Off to mgetty for check to see if mgetty is using baudboy.h locking,
bounce to pppd after that. Reassign to me if you can't figger the
/usr/include/baudboy.h re-exec of the /usr/sbin/lockdev helper.

Comment 2 Jason Vas Dias 2005-06-14 21:02:35 UTC

Just closing out old bugs here - sorry this one seems to have been
neglected for some time.

Both mgetty and pppd use their own code to create the 
/var/lock/LCK..${ttyname} files - luckily, it is now the
same file that they both try to lock, and locking works well.

So now since 2002 we've established a new "tradition", of using
/var/lock/LCK..${ttyname} . 

It seems uucp itself now uses /var/lock/LCK..${ttyname} files via
lockdev(3) for tty locks - so at least mgetty, uucp and pppd do now
all use the name lock files, if not the same code to lock them.

Perhaps pppd and mgetty should also be updated to use the lockdev(3)
functions instead of their own code for locking .

But this bug no longer seems to be an issue, so I'm closing as 
"CURRENTRELEASE" .