The change of: default_mode="0666" to default_mode="0660" causes problems with ssh-askpass because /dev/tty has the wrong permissions - so passwords become readable in the terminal. I assume a work around can be found just for the /dev/tty node - but am unsure what it is. Reproducible: Always Steps to Reproduce: 1. 2. 3.
You mean "unreadable", right? What should the "proper" permissions for /dev/tty be? Also, what should the default owner:group be? Right now we do not have a rule to specify this.
Ok, it also looks like some of the /dev/vc/tty nodes have improper permissions too. The rule: tty[0-9][0-9]*:root:tty:0660 should be catching all tty nodes, but it isn't. Hm, if you replace that line (which is in /etc/udev/permissions.d/50-udev.permissions ) with the following: tty*:root:tty:0660 and see if that fixes your problem?
Yes, I had the same problem This correction is the right stuff, it works well, and it seems good that /dev/tty is owned by root:tty
It is good that it is owned by root:tty, but the permissions of 0660 still cause me to have the same error as was originally reported :( I'll work on tweaking these tomorrow and get a new release out to fix them.
my ssh stoped working this morning, so i tracked it down, was because of this bug the fix you suggested works (after i added myself to the tty group offcourse) but, tty*:root:tty:0660 will also catch ttyUSB* etc no? maybe it would be better to just add one for tty tty:root:tty:0660
I saw this too this morning after my system rebooted - I had emerged udev-026-r1 yesterday I think. Re: comment 1 - The reporter does mean *readable*. The password characters are echoed to the tty as the program reading them could not turn echo off. And I think the proper fix is pretty close to comment #5. However, the mode for tty should be 666. So, I added the line: tty:root:tty:0666 in the pty devices area of /etc/udev/permissions.d/50-udev.permissions; rebooted, and things were working well again. Also, I did a little back tracking - this broke in udev-025-r1 with the change of the default_mode from 0666 to 0660 in udev.conf. I must not have rebooted with 025-r1. And, finally, re: comment #2, consider carefully how file globbing works compared to regex matching. 'tty[0-9][0-9]*' most definitely will not catch all tty's. I mentioned this once before for a different bug - and I think it was in either udev or hotplug also.
*** Bug 53407 has been marked as a duplicate of this bug. ***
*** Bug 53342 has been marked as a duplicate of this bug. ***
My guess is that you'd want tty[0-9]*:root:tty:0660 to catch /dev/tty as well as /dev/tty[number].
re: comment 9 - are you sure about that? On my system, /dev/tty[0-9] are symlinks that point at /dev/vc/[0-9]. What are they on your system? Does having a line like what you propose have any effect on /dev/tty[0-9]? Does it change the perms of what they point to, or the symlinks, or nothing at all?
*** Bug 53569 has been marked as a duplicate of this bug. ***
This bug is also causing nautilus (2.6+) to misbehave when you try accessing sftp sites. Before I changed permissions, it would hang when you tried accessing a share; and after I set permissions to a+rw, it segfaults. Presumably that's happening in the vfs daemon, but it's just something to watch for when fixing this bug.
The /dev/tty device is supposed to allow processes to open a new fd to their controlling terminal, so it should certainly be 0666. Programs (most notably openssh) break in mysterious ways if they can't open /dev/tty. The solution seems to be adding a line to /etc/udev/permissions.d/50-udev.permissions: tty:root:tty:0666 right before the rule that matches the rest of the ttys.
Fixed in 027 release.
Only a note. There is some misinterpretation of udev rules I think. The rule tty[0-9]* should be explained this way: Match an identified starting with the letters "tty", followed by any single digit, optionally followed by anything at all. This is NOT a regular expression saying "string 'tty' and any digit repeated zero or more times". Explained in `man udev`.
*** Bug 53837 has been marked as a duplicate of this bug. ***
*** Bug 55989 has been marked as a duplicate of this bug. ***
How about marking 0.27 (or higher) stable on x86 so that this bug won't keep affecting people?
Good idea, I just did that right now.
