Description of problem: sudo does not use pam_xauth in its pam config file so that when ssh'd in remotely to a server and you type sudo su - and try and run an x client (such as up2date) you get something like this: [root@pedro root]# up2date -l X11 connection rejected because of wrong authentication. [root@pedro root]# echo $DISPLAY localhost:15.0 or [mgalgoci@razor mgalgoci]$ ssh pedro.ges.redhat.com mgalgoci@pedro's password: [mgalgoci@pedro mgalgoci]$ sudo su - [root@pedro root]# xeyes X11 connection rejected because of wrong authentication. X connection to localhost:11.0 broken (explicit kill or server shutdown). [root@pedro root]# echo $DISPLAY localhost:11.0 Not that I really wanted to use the gui up2date client in the first place, it is nevertheless a bug in sudo's configuration. Steps to Reproduce: 1. ssh to a machine as a user 2. sudo su - to root 3. try to run an X application. Actual results: X authentication is rejected. Expected results: My xauth credential should be forwarded by pam_xauth to my root session and my X client should authenticate run.
It is not a good idea to give access to the X11 session per se. If the user has restricted access to not-X11 programs, he can get access to the full X11 session with this. Closing as won't fix.
Usermod is apparently at fault here because /usr/bin/up2date is a symlink to consolehelper. Alternatively, consolehelper should not fail critically if it barfs on xauth, and instead should fall back to console mode.
This should probably be re-assigned to nalin :)
When an X11 session is rejected as described in comment 0, gtk_init_check () or something it uses calls exit (1) instead of returning FALSE.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.