Bug 179841 - usb to serial convert wrong permission
usb to serial convert wrong permission
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Depends On:
  Show dependency treegraph
Reported: 2006-02-03 06:22 EST by Levente Farkas
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-28 05:45:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
50-udev.rules (12.46 KB, text/plain)
2006-02-14 05:04 EST, Harald Hoyer
no flags Details

  None (edit)
Description Levente Farkas 2006-02-03 06:22:52 EST
Description of problem:
when you plug an usb to serial converter, the udev create a ttyUSBx device for
you, but it was created as root:uucp 0660. imho it should have to be created as
0666 since it's always use by enduser. and in this case the desktop user are not
able to use that device. i don't realy think it's a security issue either.
what's more when i create a file /etc/udev/rules.d/10-ttyUSB.rules :
KERNEL=="ttyUSB*",              GROUP="uucp", MODE="0666"
KERNEL=="tts/USB[0-9]*",        GROUP="uucp", MODE="0666"
it's not working. ie. the device still created in 0660 mode. why?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Russell Strong 2006-02-04 17:33:06 EST
The following rules used to work.  The simlink is still created, but the
permissions are 660 instead of 666

KERNEL="ttyS0", NAME="%k", MODE="0666", SYMLINK="dasboot"
KERNEL="ttyUSB*", NAME="%k", MODE="0666"

Stopped working after updating to:
Comment 2 James Ralston 2006-02-10 16:09:17 EST
The problem is that the algorithm udev uses to load the rules changed between
udev-058-1.0.FC4.1 and udev-071-0.FC4.2.

In udev-058, either rule processing stopped on the first match, or successive
rules could add to existing rules but not override them.  (I've been unable to
determine which.)

In udev-071, not only does rule processing *not* stop on the first match, but
successive rules override prior rules in case of a conflict.

In your case, in your 10-ttyUSB.rules file, you have:

KERNEL=="ttyUSB*", GROUP="uucp", MODE="0666"
KERNEL=="tts/USB[0-9]*", GROUP="uucp", MODE="0666"

But 50-udev.rules says:

KERNEL=="ttyS*", GROUP="uucp", MODE="0660", OPTIONS="last_rule"

Both KERNEL=="ttyUSB*" (from 10-ttyUSB.rules) and KERNEL=="ttyS*" (from
50-udev.rules) match.  The rule from 10-ttyUSB.rules is applied first, which
sets MODE="0666".  But then the rule from 50-udev.rules is also applied, which
sets MODE="0660".  As a result, the device is created mode 0660.

The solution is to use the "last_rule" option.  This option stops further rule
application if the rule that has the last_rule option matches.

So, if you use the last_rule option in the rules you specify in 10-ttyUSB.rules,
the rules in 50-udev.rules won't be applied, and your ttyUSB devices will be
created mode 0666, as you wanted:

KERNEL=="ttyUSB*", GROUP="uucp", MODE="0666", OPTIONS="last_rule"
KERNEL=="tts/USB[0-9]*", GROUP="uucp", MODE="0666", OPTIONS="last_rule"

IMHO, the udev maintainers really dropped the ball on this one.  It made sense
to change the rule processing behavior, because being able to "stack" rules with
overrides offers a lot more flexibility in writing them.  But I'll be damned if
I can find *any* announcement of this behavior change anywhere in the udev
documentation.  Given that this behavior change had the potential to break many
people's rules (i.e., everyone who wasn't already using the last_rule option in
their own rules), the change in behavior should be repeatedly announced and
emphasized throughout the documentation.
Comment 3 James Ralston 2006-02-10 16:43:50 EST
See also bug #180973, which is (IMHO) a better way to allow a non-root user to
access the ttyS* files.
Comment 4 Peter Bieringer 2006-02-11 11:20:21 EST
Can one create a script which compares the current owner/group/permissions of
entries in /dev with the udev rules definition to check, which rules are not

Current situation is really bad and it looks like that "last_rule" didn't help
sometimes (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179993)

Now we are back in times where all scripts have to start as root, change
owner/group/permissions and then drop root :-(
The second fight after the delay problem in udev (e.g. modprobe device_module,
wait about 10 to 20 seconds until device appears in /dev and continue)...

I'm not really happy...
Comment 5 Harald Hoyer 2006-02-14 02:12:55 EST
You should really use pam_console for this. Add a file to
/etc/security/console.perms.d and the permissions will be set to the console user.
Comment 6 Harald Hoyer 2006-02-14 05:04:24 EST
Created attachment 124606 [details]

Does this 50-udev.rules fix your issues?
Comment 7 Harald Hoyer 2006-02-15 07:25:54 EST
Comment 8 Levente Farkas 2006-02-15 07:44:29 EST
what is the real question?
- i still not try the /etc/security/console.perms.d since i've to read the
console.perms manual and write a new perms file (and this week i don't have any
- i still not try other refered bugzilla solutions
- i donwload your new file
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124606 but it still
contains 0660 as aq permission. even if i has a 10-ttyUSB.rules it was created
as 0660 so this is not a solution either.

may be later this day i'll spend a half an hour to find any solution.
Comment 9 Levente Farkas 2006-02-15 10:42:27 EST
this solve my problem /etc/security/console.perms.d/10-usbserial.perms :
# device classes -- these are shell-style globs

# permission definitions
<console>  0660 <usbserial>  0660 root
which seems to a better solution the /etc/udev/rules.d/10-ttyUSB.rules
shouldn't this bugzilla have to reassing to the pam package? it'd be better if
the above perms would be included in the pam's 50-default.perms.

Note You need to log in before you can comment on or make changes to this bug.