Description of problem: Pseudo-teminal assigned to an xterm window (/dev/pts/NN) gets wrong group ('root' instead of 'tty' which is supposed to be default as set in fstab: none /dev/pts devpts gid=5,mode=620 0 0 This makes impossibloe to use 'talk', 'mesg' etc. all of which fail reporting "your party is refusing connection" (talk), "error: tty device is not owned by group `tty'" (mesg). Other X11 terminal apps (like 'konsole') work fine. Version-Release number of selected component (if applicable): xorg-x11-6.7.0-5 How reproducible: always Steps to Reproduce: 1.start X Windows (any desktop/window manager, I checked KDE, XFce 3 and 4, twm 2.start an xterm window 3.run 'tty', then 'ls -l /dev/pts/NN' Actual results: >tty /dev/pts/20 >ls -l /dev/pts/20 crw--w---- 1 msz root 136, 20 Aug 4 16:12 /dev/pts/20 Expected results: >ls -l /dev/pts/20 crw--w---- 1 msz tty 136, 20 Aug 4 16:12 /dev/pts/20 Additional info: I am not sure whether this is really an 'xterm' issue but since 'konsole' works OK, I put 'xterm' as the Component.
Actually, since xterm isn't running setuid, I would assume the appropriate component is the utempter application.
Pam configuration issue?
Permissions on /dev/pts aren't handled by pam.
The xterm package is being compiled in the build system with TTY_GROUP_NAME set to "root" instead of "tty" (reproduce by running rpmbuild with stdin redirected from /dev/null), so the set_owner() function in xterm attempts to set the group owner of the PTY device to 0 after the kernel has already set it correctly. Reassigning to the xterm package.
Assuming that it is set from the configure script, that comes from the group name of /dev/tty at the time xterm is configured and built.
Applications shouldn't assume that the OS they're being built under is the OS they'll be ran under IMHO. That has caused a lot of grief in the past, including with other parts of X, such as the input devices assuming that because the buildsystem is using a 2.2 kernel, it should configure the X build to assume it will be running under a 2.2 kernel. That caused USB support to be dropped from wacom driver a long time ago, or something of that nature. Just my own personal opinion mind you.. ;o)
Since I cannot possibly guess what Redhat's rpm file will do with the configure script, it probably should be fixed in the rpm file (which presumably has some notion about the dependencies). The configure script can only make useful assumptions about the system that it's being run on.
This bug is now fixed with xterm-205-1 in Rawhide (will submit to FC-4 shortly). The tty group name is now set with an environment variable XTERM_TTY_GROUP_NAME in the .spec file, and the xterm-205/configure script is patched to let this variable override the invocation of the CF_TTY_GROUP macro if set. I'd have liked to patch the configure.in and run autoconf, but owing to use of custom patched autoconf-2.13 and AC_DIVERT_HELP macro by upstream aclocal.m4, this was not possible. It would be great to convert the upstream autoconf files shipped with xterm to provide all macros which are not part of autoconf-2.5x as macros in aclocal.m4 .
From User-Agent: XML-RPC xterm-205-1.FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
This was indeed pushed into FC4 updates, and presumably there were no further problems. Marking resolved.