Bug 722703
| Summary: | DISPLAY is not exported in xfce4 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David A. De Graaf <dad> |
| Component: | pam | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 15 | CC: | kdudka, kevin, maxamillion, ovasik, tmraz, twaugh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-08-07 20:18:10 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: | |||
I have a very hard time seeing how Xfce could be involved here. What does: 'su -c 'rpm -V coreutils'' show on the problem machines? Have you modified /etc/pam.d/su* ? Does 'su -m -' export the env as you expect? On the defective IBM T30 laptop: [dad@datxxx ~] $ rpm -q coreutils coreutils-8.10-2.fc15.i686 [dad@datxxx ~] $ su -c 'rpm -V coreutils' Password: [dad@datxxx ~] $ echo $DISPLAY :0 [dad@datxxx ~] $ ls -l /etc/pam.d/su* -rw-r--r--. 1 root root 487 Feb 8 06:38 /etc/pam.d/su -rw-r--r--. 1 root root 137 Feb 8 06:38 /etc/pam.d/su-l -rw-r--r-- 1 root root 202 Jun 3 09:35 /etc/pam.d/sudo -rw-r--r-- 1 root root 187 Jun 3 09:35 /etc/pam.d/sudo-i [dad@datxxx ~] $ su -m - Password: [root@datxxx ~] # echo $DISPLAY [root@datxxx ~] # ==================================================== On the well-behaved ASUS N10 netbook: [dad@datasus ~] $ rpm -q coreutils coreutils-8.10-2.fc15.i686 [dad@datasus ~] $ su -c 'rpm -V coreutils' Password: [dad@datasus ~] $ echo $DISPLAY :0 [dad@datasus ~] $ ls -l /etc/pam.d/su* -rw-r--r--. 1 root root 487 Feb 8 06:38 /etc/pam.d/su -rw-r--r--. 1 root root 137 Feb 8 06:38 /etc/pam.d/su-l -rw-r--r--. 1 root root 202 Jun 3 09:35 /etc/pam.d/sudo -rw-r--r--. 1 root root 187 Jun 3 09:35 /etc/pam.d/sudo-i [dad@datasus ~] $ su -m - Password: [root@datasus ~] # echo $DISPLAY :0 [root@datasus ~] # ==================================================== On both machines, rpm -V coreutils reports no changes. I have made no changes in either /etc/pam.d/ directories. The first machine fails to export DISPLAY, while the second machine does it correctly. Thank you for you interest and quick response. What more info can I provide? Any differences between /root/.bash* on the working/non working boxes? How about /etc/bashrc and /etc/profile* ? There are no differences in /root/.bash* except in .bash_history :-)
There are non-significant differences in /etc/bashrc, eg:
$ diff /net/datxxx/etc/bashrc /net/datasus/etc/bashrc
39d38
< alias psg="ps -ef | grep "
42c41,42
< export MANOPT="-a "
---
> export MANOPT="-a"
> # /usr/bin/numlockx on > /dev/null 2>&1
There are no differences in /etc/profile or in /etc/profile.d/*
I remain baffled.
I'm pretty puzzled here too. ;( Perhaps lets move this over to coreutils and see if they have any ideas? su from coreutils does not handle $DISPLAY and $XAUTHORITY any more, pam_xauth does. See bug 622700 for details. Adding Tomas Mraz to CC ... I have a brute-force workaround and an incomprehensible solution. To force a root window to have DISPLAY defined, I add to /root/.bashrc these lines: # dad added export DISPLAY=:0 This "works", but only in limited conditions. Clearly, it won't work if another user starts up a second X server, with a different DISPLAY value. Need I remind everyone that: 1 - Linux is, first and foremost, a multi-user system. 2 - X is just another application; not the end-all and be-all. The "solution" was found on someone's blog (that I've lost). I offer it in hope that it may provide a clue to the real problem. Add this line to $HOME/.initrc: ck-launch-session dbus-launch --sh-syntax --exit-with-session startxfce4 and then use startx instead of startxfce4 to begin the X session. This has a side benefit of somehow persuading that massive pile of poo called "pam" that I should actually be allowed to edit my NetworkManager connections and to edit my PowerManager settings. It also magically restores the Hibernate and Suspend 'buttons' to the PowerManager applet, and restores the Shutdown, Suspend, and Hibernate buttons to the Logout icon, all of which were either absent or greyed out. I don't understand how or why this works. The need to do it is clearly a bug. pam is responsible for setting $DISPLAY accordingly. If not, I would say it is either misconfigured or broken. Did you change anything in /etc/security/pam_env.conf ? By using words like "massive pile of poo called pam" you clearly will not make the bug any higher priority. :) So you're running the xfce session on both the laptops with startx? What do you see in /var/log/secure if you add debug option to the pam_xauth line in the /etc/pam.d/su ? Kamil: I have made no changes in any file related to pam. On both laptops the files in /etc/security and in /etc/pam.d are identical. For several years I have studiously avoided dealing with pam in any way, a strategy that has worked well - until F15. And pam has been cooperative and done nothing to impose any new requirements on me. As for me, the traditional rwxrwxrwx controls are perfectly adequate. Tomas: Forgive me for venting my massive frustrations in this venue over all the things that F15 has broken which used to work perfectly. Pam is only one part of it all. I should probably reiterate my traditional - now considered odd - but valid method of starting Linux. I use init level 3 (rather, multi-user.target: analogous to runlevel 3), disable rhgb to see what's going on, log in at the console prompt, and then run startxfce4 to begin the X session, avoiding Gnome entirely. Except now having discovered the apparent bug, I must run startx with that cryptic line in ~/.xinitrc. You ask me to add debug option in the pam_xauth line. Is this what you mean? session optional pam_xauth.su debug with the last word added? With that modified line in /etc/pam.d/su, I rebooted the IBM T30 laptop, then ran startxfce4, killed X, and then ran startx. Here's the entire contents of /var/log/secure from my login at 12:35:02. Contents of /var/log/secure with debug set startxfce4: Aug 24 12:35:02 datxxx login: pam_unix(login:session): session opened for user dad by LOGIN(uid=0) Aug 24 12:35:03 datxxx login: LOGIN ON tty1 BY dad Aug 24 12:36:07 datxxx polkitd(authority=local): Registered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.35 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) I kill X with CTL-ALT-BS, then run startx: w/line in .xinitrc Aug 24 12:39:45 datxxx polkitd(authority=local): Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.35, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) Aug 24 12:39:45 datxxx su: pam_unix(su-l:auth): conversation failed Aug 24 12:39:45 datxxx su: pam_unix(su-l:auth): auth could not identify password for [root] Aug 24 12:39:45 datxxx su: pam_unix(su-l:auth): conversation failed Aug 24 12:39:45 datxxx su: pam_unix(su-l:auth): auth could not identify password for [root] Aug 24 12:39:45 datxxx su: pam_unix(su-l:auth): conversation failed Aug 24 12:39:45 datxxx su: pam_unix(su-l:auth): auth could not identify password for [root] Aug 24 12:40:11 datxxx polkitd(authority=local): Registered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session2 (system bus name :1.54 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Obviously the two startups are different. Why is the first method "Registered" but the second "Unregistered"? I hope this info is meaningful to you; it isn't to me. Unfortunately they do not make sense to me either. I do not see su being called at all in the first case and in the second case it failed completely to authenticate the root? So pam_xauth never gets to run. This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |
Description of problem: DISPLAY is not exported Version-Release number of selected component (if applicable): xfce-utils-4.8.2-1.fc15.x86_64 How reproducible: Always on two machines; never on two other machines. Steps to Reproduce: 1. In any kind of terminal emulator, eg, xterm, Terminal, etc, display exported variables, displaying declare -x DISPLAY=":0.0" ; echo $DISPLAY, see :0.0 2. Run /bin/su - ; supply the passwd 3. echo $DISPLAY; see blank line Actual results: DISPLAY is blank Expected results: DISPLAY should have value of parent process Additional info: In xfce4, the environment variable, DISPLAY, is not exported to a child root process by the command /bin/su - The export command on the non-root parent process shows: declare -x DISPLAY=":0" However, the value of DISPLAY for the child process is blank. I've tested this with many terminals in xfce4: /usr/bin/Terminal /usr/bin/gnome-terminal /usr/bin/lxterminal /usr/bin/pterm /usr/bin/uxterm /usr/bin/xfterm4 /usr/bin/xterm and all fail to export DISPLAY. However, while using gnome the export of DISPLAY is done correctly. With DISPLAY undefined, it is impossible for root to execute critical GUI commands, such as system-config-*. This annoying defect first appeared in Fedora 15. The most puzzling fact is that it happens only on two of the four PCs on which I've freshly installed F15. All have received substantially the same set of packages. I'm still searching for the difference... I created a new user with a blank-slate $HOME, but the problem persists - on the affected machines. Switching to another user with /bin/su - otheruser also fails to export DISPLAY on the affected machines, so the problem is not some mysterious su security thing, either. It seems to be exclusively xfce4-related. Clues to the source of this defect would be welcome.