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
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):
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'
>ls -l /dev/pts/20
crw--w---- 1 msz root 136, 20 Aug 4 16:12 /dev/pts/20
>ls -l /dev/pts/20
crw--w---- 1 msz tty 136, 20 Aug 4 16:12 /dev/pts/20
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.