Red Hat Bugzilla – Bug 180973
ttyS* files should be owned by the console user
Last modified: 2007-11-30 17:11:23 EST
In 50-udev.rules, we have: KERNEL=="ttyS*", GROUP="uucp", MODE="0660", OPTIONS="last_rule" I would argue that this default is fantastically unhelpful. The ttyS* devices are most commonly used for sync'ing handheld devices. In virtually all cases, the software attempting to read the device (e.g. pilot-xfer) will be running as the user who is logged into the machine, not as root. Thus, the default file owner/group/perm settings prevent them from access the device file. Overriding the permissions on /dev/ttyS* seems to be the #1 reason why most people bother to write their own udev rules. Even worse, when they do, they usually take the path of least resistance and make the devices mode 0666, which is undesirable because it gives any random person on the machine the ability to manipulate their device. IMHO, this would be a much better default: KERNEL=="ttyS*", PROGRAM="/etc/udev/scripts/console-user.sh", OWNER="%c", GROUP="uucp", MODE="0660", OPTIONS="last_rule" The console-user.sh script is a very simple script that will print the username of the person logged in on the console, or "root" if no console user could be identified. As a result, the ttyS* files will be owned by whoever is logged in on the console of the machine. Does this sound reasonable?
Created attachment 124532 [details] A udev script to return the console user, or root if there is no console user.
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.
udev-071-0.FC4.2 seems broken for this, in 50-default.perms I changed the line about the pilot to <pilot>=/dev/ttyUSB* /dev/pilot and when devices are created ownership is not changed to console user
Created attachment 124603 [details] 50-udev.rules Does this 50-udev.rules fix the pilot issue?
yes, thanks. Ownership and permissions are good now. I also noticed that I no longer need /dev/ttyUSB* in /etc/security/console.perms.d/50-default.perms and also, with your new file /dev/pilot has been created, this will help a lot of folks who were having problems and resorting to fixes like the one on the udev page http://fedora.redhat.com/docs/udev/ which set dev permissions to 666 (could that page be updated if this fix goes through?)
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.
In reply to comment #4: when I tested that 50-udev.rules file (after removing all of my own custom rules), I got: $ ls -lsa /dev/pilot /dev/ttyUSB* 0 lrwxrwxrwx 1 root root 7 Feb 15 18:22 /dev/pilot -> ttyUSB1 0 crw------- 1 ralston uucp 188, 0 Feb 15 18:22 /dev/ttyUSB0 0 crw------- 1 ralston uucp 188, 1 Feb 15 18:24 /dev/ttyUSB1 IMHO, this is the Correct Thing (tm) for Palm devices. I have one question, though: what magic is in this 50-udev.rules file that causes the /dev/ttyUSB* devices to be owned by the console user, instead of by root? By my reading, they should wind up being owned by root, but they clearly aren't. I'm not complaining--I think the ttyUSB* files SHOULD be owned by the console user--but I can't see how that 50-udev.rules file produces that outcome. (I don't have anything in /etc/security/console.perms.d, so it can't be coming from there.)
$ fgrep pilot /etc/security/console.perms.d/50-default.perms <pilot>=/dev/pilot <console> 0600 <pilot> 0660 root.uucp
Ah, ok. Someone recently added rules targeting /dev/pilot to 50-default.perms. All that was missing was the udev logic to make sure that /dev/pilot actually got created. Yes, I agree that this is a much better solution than having udev change the ownership itself. (As a matter of fact, the only reason I did the ownership change using udev instead of via 50-default.perms was because I thought that surely /dev/pilot would have already been in 50-default.perms if that were the best way to accomplish the ownership change. Better late than never, I suppose.)