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? yours. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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: udev-071-0.FC4.2
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.
See also bug #180973, which is (IMHO) a better way to allow a non-root user to access the ttyS* files.
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 working? 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...
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.
Created attachment 124606 [details] 50-udev.rules Does this 50-udev.rules fix your issues?
ping?
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 time). - 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.
this solve my problem /etc/security/console.perms.d/10-usbserial.perms : -------------------------- # device classes -- these are shell-style globs <usbserial>=/dev/ttyUSB* # 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.