Hide Forgot
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.
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).
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