Bug 74454 - Can't get lock on /dev/usb/ttyUSBx
Summary: Can't get lock on /dev/usb/ttyUSBx
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lockdev (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: All Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Brian Brock
: 98160 126082 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-09-24 17:08 UTC by Nathan Crapo
Modified: 2007-04-18 16:46 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-23 12:58:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Nathan Crapo 2002-09-24 17:08:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
When lockdev is called with /dev/usb/ttyUSBx, it redirects part of the locking
process to /dev/ttyUSBx when it makes a call to ttyname().  That's fine as long
as the user sets permissions on /dev/ttyUSBx as well as /dev/usb/ttyUSBx, but
IMHO, the user shouldn't have to mess with *two* dev nodes just to get a lock. 
Users will not be able to tell what is happening from an application level anyhow.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Set permissions on /dev/usb/ttyUSB0 to 666.  You must have a serial USB
adapter to open this particular device.  You could possibly set up a similar
scenario by creating a devnode in another directory such as /dev/testdir/ttyS0.
2.  Set permissions on the duplicate dev node in the dev directory to 600, or
something similar.  We want to deny normal users from getting a lock on it.
3.  Try getting a lock on the device (type "lockdev -l /dev/usb/ttyUSB0").  It
will fail even though permissions are set correctly on the specified devnode. 
You can tell by doing "ls /dev/lock" or by writing a small shell script to print
the return code from lockdev.
4.  Change permissions on /dev/ttyUSB0 to 666 and try to get the lock on
/dev/usb/ttyUSB0 again.  It should work.  I don't think getting a lock on
/dev/usb/ttyUSB0 should depend on the permissions of /dev/ttyUSB0.

Actual Results:  Getting a lock on the specified device with correct permissions
does not always work.

Expected Results:  The lock should be made on the devnode as specified and not
depend on another devnode's permissions.

Additional info:

Maybe we have two copies of the devnode by default for convenience sake?  Having
two was a source of confusion in the first place.  Once I found the devnode I
was looking for, I didn't bother to look for a second one.  I especially didn't
think that I would be trying to get the lock on a devnode other than what I

Comment 1 Kenn Humborg 2002-11-02 23:45:15 UTC
I think lockdev will fail pretty much all the time when
the device file is in a subdirectory of /dev. 

For example, trying to claim a lock on /dev/lat/foo 
results in lockdev failing to stat /dev/foo (as shown
by strace).

I can only assume that this will get more commonplace as
more and more stuff gets moved to subdirs of /dev (or 
devfs is used).

Comment 2 Kenn Humborg 2002-11-02 23:47:28 UTC
In addition, perhaps lockdev should use /var/lock/LOCK..dir.dir.file
for device files in subdirs?

Otherwise there is the potential for collisions.

Comment 3 Francois Staes 2003-01-12 12:07:33 UTC
Got a similar problem with ttyACM0.
As there are no entries for ACM's within /dev, one
has to create a symbolic link pointing from /dev/ttyACM0
to /dev/input/ttyACM0 in order to make locking work.

Comment 4 Karel Zak 2005-02-23 11:35:24 UTC
*** Bug 98160 has been marked as a duplicate of this bug. ***

Comment 5 Karel Zak 2005-02-23 11:35:45 UTC
*** Bug 126082 has been marked as a duplicate of this bug. ***

Comment 6 Karel Zak 2005-02-23 12:58:59 UTC
Fixed in devel branch.

The solution is like in the pppd: 
    /dev/input/ttyACM0 --> /var/lock/LCK..input_ttyACM0

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