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):
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.
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
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
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).
In addition, perhaps lockdev should use /var/lock/LOCK..dir.dir.file
for device files in subdirs?
Otherwise there is the potential for collisions.
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.
*** Bug 98160 has been marked as a duplicate of this bug. ***
*** Bug 126082 has been marked as a duplicate of this bug. ***
Fixed in devel branch.
The solution is like in the pppd:
/dev/input/ttyACM0 --> /var/lock/LCK..input_ttyACM0