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

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