Bug 129146
Summary: | wrong group of xterm pseudo terminal | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Szymanski <msz> |
Component: | xterm | Assignee: | Jason Vas Dias <jvdias> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | 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
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. 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. |