Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 74454

Summary:	Can't get lock on /dev/usb/ttyUSBx
Product:	[Retired] Red Hat Linux	Reporter:	Nathan Crapo <nathan_crapo>
Component:	lockdev	Assignee:	Karel Zak <kzak>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	fstaes, jreiser
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-02-23 12:58:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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