Description of problem: mesg n does not actually prevent messages, and mesg y consistently produce an error message. Version-Release number of selected component (if applicable): SysVinit-2.86-2.2.2 How reproducible: Happens every time Steps to Reproduce: 1. Open xterm 2. Type "mesg y" Actual results: mesg: error: tty device is not owned by group `tty' Expected results: No errors Steps to Reproduce: 1. Open xterm 2. Type "mesg n" 3. ls -l $(tty) Actual results: crw-----w- 1 kasperd kasperd 136, 14 Dec 9 18:26 /dev/pts/14 Expected results: No write permission for others Additional info: Even when messages are enabled, it is a bad idea to allow every user to write the device directly. The write command makes it clear that a message was send, and who did it. Direct writes can be used to fake tty output.
I can't reproduce this, although this is on FC6: [notting@nostromo: ~]$ ls -l $(tty) crw--w---- 1 notting tty 136, 2 Dec 11 15:23 /dev/pts/2 [notting@nostromo: ~]$ mesg n [notting@nostromo: ~]$ ls -l $(tty) crw------- 1 notting tty 136, 2 Dec 11 15:23 /dev/pts/2 [notting@nostromo: ~]$ mesg y [notting@nostromo: ~]$ ls -l $(tty) crw--w---- 1 notting tty 136, 2 Dec 11 15:23 /dev/pts/2 What sort of tty rules do you have in /etc/udev/rules.d?
I have just the /etc/udev/rules.d/50-udev.rules from udev-084-13.fc5.2
ownership and permissions of ptys are not set by udev, afaik
What's your line for /dev/pts in /etc/fstab?
[kasperd@localhost:pts/7:~] grep pts /etc/fstab /dev/devpts /dev/pts devpts gid=5,mode=620 0 0 [kasperd@localhost:pts/7:~]
/dev/pts is not managed by udev
I just noticed that I can only reproduce the problem in xterm. Konsole, script, and screen are not affected by this.
mlichvar reported that only FC6, FC5 and RHEL5 are affected. The problem is caused by obsolete patch for configure script that is no longer needed.
Fixed in xterm-223-1.fc5 xterm-223-1.fc6 Removing "Security sensitive" flag.
xterm-223-1.fc5 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.