Bug 58807 - Ownership problem of /var/lock and non-use of /var/lock/uucp
Ownership problem of /var/lock and non-use of /var/lock/uucp
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: mgetty (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-24 17:35 EST by Nick Craig-Wood
Modified: 2007-04-18 12:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-14 17:02:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nick Craig-Wood 2002-01-24 17:35:32 EST
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 16:57:58 EST
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 17:02:35 EDT
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" .




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