From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Red Hat/1.0.6-1.4.1 Firefox/1.0.6 Description of problem: system-config-date fails when launched in an SSH tunnel with an error message claiming that the connection was lost and that the X server was probably shut down. This would be believable had I not started it from a remote gnome-terminal (also running via SSH tunnel) which was still fine. It's not strangeness from use of 'sudo' as other apps can be launched as well (firefox, recursive gnome-terminals). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. ssh -X hostname 2. sudo gnome-terminal 3. /usr/bin/system-config-date 4. pain and disappointment Actual Results: [root@worthless-rhel-box ~]# system-config-date The application 'system-config-date.py' lost its connection to the display localhost:11.0; most likely the X server was shut down or you killed/destroyed the application. [root@gep-kaiser-rh ~]# which system-config-date /usr/bin/system-config-date Additional info:
What version of system-config-date is the one that is not working? And, is this RHEL4 U1? I am unable to repeat with a quick check on one of our RHEL4 U1 i386 boxes, including the running through a remote gnome-terminal part. Please give hardware information on the box in question. Also, could you possibly test it on another RHEL4 U1 box, to see if it's just that one machine?
"rpm -qf /usr/bin/system-config-date" gives "system-config-date-1.7.15-0.RHEL4.1". Red Hat Desktop release 4 (Nahant Update 1) on both ends. I tried ssh -X to another machine and discovered that the problem only results when using sudo to become root -- I have sudo access to one machine, and can use sudo _or_ su on the machine that I most recently tested. Running 'su xterm', then launching system-config-date from the xterm, succeeds. Running 'sudo xterm', then launching system-config-date from the xterm, fails. Both systems are i686. One is a Compaq with 256MB RAM, the other an HP with 512MB. I can provide additional hardware if needed. Specific output from system-config-date follows: [root@machine ~]# system-config-date The application 'system-config-date.py' lost its connection to the display localhost:10.0; most likely the X server was shut down or you killed/destroyed the application. [root@machine ~]#
I've often seen this with other X applications when using sudo, it apparently doesn't pass on X credentials (as su does), not even when appending a pam_xauth line to /etc/pam.d/sudo like this one: session optional pam_xauth.so Apparently, for reasons unknown, sudo doesn't like pam_xauth enough so that X credential forwarding would work. Reassigning to sudo.
The command sudo doesn't use PAM session that is usefull for xauth. In the distributions <= RHEL4-U1 or RHEL3-U5 is PAM session fully unsupported. And in the new versions will be limited PAM session support only. All sudo versions use exec(your_command) that replace original sudo process -- so there is no place where we can call pam_sesssion_close(). (Yes, there's Red Hat specific SeLinux wrapper "sesh" that uses fork(), but it's useless for PAM session). You have to use "su" or ask upstream for change in some future version. Sorry. WONTFIX.
Is there somewhere I could have learned that PAM session is "fully unsupported"? It was my impression that Red Hat offered full support for packages distributed in the standard channels.
It's misunderstanding. I didn't talk about Red Hat support service. I talked about "sudo+PAM session" feature. PAM session is __not implemented__ in the sudo command (other words -- it isn't supported feature by sudo). It isn't bug -- the sudo design doesn't expect something like PAM sessions. I think you should talk about it with official Red Hat Global Service rather than with developers in Bugzilla. Thanks.
(*grin*) It's a bug when something doesn't work and I want it to! Thanks for your kind responses. Google tells me that you've made efforts to get sudo to play somewhat nicely with PAM, and I do appreciate your efforts towards a quality product.
*** Bug 69025 has been marked as a duplicate of this bug. ***
BTW: To overcome that limitation of sudo, mkxauth comes handy, i.e. as root do this: mkxauth -m <normal user> to merge the normal user's X credentials into root's.
*** Bug 142648 has been marked as a duplicate of this bug. ***