Bug 129146

Summary: wrong group of xterm pseudo terminal
Product: [Fedora] Fedora Reporter: Michal Szymanski <msz>
Component: xtermAssignee: Jason Vas Dias <jvdias>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: dickey, nalin, riel, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 05-1.FC4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-07 18:00:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150221    

Description Michal Szymanski 2004-08-04 14:13:33 UTC
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.

Comment 1 Thomas E. Dickey 2004-08-04 19:48:36 UTC
Actually, since xterm isn't running setuid, I would assume
the appropriate component is the utempter application.

Comment 3 Mike A. Harris 2005-04-11 19:12:40 UTC
Pam configuration issue?

Comment 4 Tomas Mraz 2005-04-11 19:59:37 UTC
Permissions on /dev/pts aren't handled by pam.


Comment 5 Nalin Dahyabhai 2005-07-21 20:12:47 UTC
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.

Comment 6 Thomas E. Dickey 2005-07-21 21:17:27 UTC
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.

Comment 7 Mike A. Harris 2005-09-14 10:47:00 UTC
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)

Comment 8 Thomas E. Dickey 2005-09-14 13:10:06 UTC
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.

Comment 9 Jason Vas Dias 2005-10-13 00:56:03 UTC
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 . 

Comment 10 Fedora Update System 2005-11-07 19:31:50 UTC
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.

Comment 11 Fedora Update System 2005-11-14 18:02:19 UTC
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.

Comment 12 Matthew Miller 2006-07-07 18:00:23 UTC
This was indeed pushed into FC4 updates, and presumably there were no further
problems. Marking resolved.