Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 74454 - Can't get lock on /dev/usb/ttyUSBx
Summary: Can't get lock on /dev/usb/ttyUSBx
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lockdev
Version: 7.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Brian Brock
URL:
Whiteboard:
: 98160 126082 (view as bug list)
Depends On:
Blocks:
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:
Clone Of:
Environment:
Last Closed: 2005-02-23 12:58:59 UTC
Embargoed:

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:
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 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.