Bug 164671 - system-config-date fails with X-over-SSH
system-config-date fails with X-over-SSH
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: sudo (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
:
: 69025 142648 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-29 17:00 EDT by Chester Hosey
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-02 06:04:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chester Hosey 2005-07-29 17:00:20 EDT
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:
Comment 1 Suzanne Hillman 2005-08-01 14:33:28 EDT
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?
Comment 2 Chester Hosey 2005-08-01 14:49:39 EDT
"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 ~]# 
Comment 3 Nils Philippsen 2005-08-02 04:06:14 EDT
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.
Comment 4 Karel Zak 2005-08-02 06:04:15 EDT
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.

Comment 5 Chester Hosey 2005-08-02 08:43:23 EDT
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.
Comment 6 Karel Zak 2005-08-02 09:42:10 EDT
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.
Comment 7 Chester Hosey 2005-08-02 09:47:36 EDT
(*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.
Comment 8 Karel Zak 2005-08-03 08:25:26 EDT
*** Bug 69025 has been marked as a duplicate of this bug. ***
Comment 9 Nils Philippsen 2005-08-03 08:27:53 EDT
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.
Comment 10 Karel Zak 2006-04-09 15:42:58 EDT
*** Bug 142648 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.