Bug 74454 - Can't get lock on /dev/usb/ttyUSBx
Can't get lock on /dev/usb/ttyUSBx
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: lockdev (Show other bugs)
7.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Brian Brock
:
: 98160 126082 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-24 13:08 EDT by Nathan Crapo
Modified: 2007-04-18 12:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-23 07:58:59 EST
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 Nathan Crapo 2002-09-24 13:08:27 EDT
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:
Always

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
specified.
Comment 1 Kenn Humborg 2002-11-02 18:45:15 EST
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 18:47:28 EST
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 07:07:33 EST
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 06:35:24 EST
*** Bug 98160 has been marked as a duplicate of this bug. ***
Comment 5 Karel Zak 2005-02-23 06:35:45 EST
*** Bug 126082 has been marked as a duplicate of this bug. ***
Comment 6 Karel Zak 2005-02-23 07:58:59 EST
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.