Bug 722703 - DISPLAY is not exported in xfce4
DISPLAY is not exported in xfce4
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
15
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-16 15:06 EDT by David A. De Graaf
Modified: 2012-08-07 16:18 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-07 16:18:10 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 David A. De Graaf 2011-07-16 15:06:17 EDT
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.
Comment 1 Kevin Fenzi 2011-07-16 15:22:21 EDT
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?
Comment 2 David A. De Graaf 2011-07-16 16:06:01 EDT
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?
Comment 3 Kevin Fenzi 2011-07-16 18:47:36 EDT
Any differences between /root/.bash* on the working/non working boxes?

How about /etc/bashrc and /etc/profile* ?
Comment 4 David A. De Graaf 2011-07-18 15:18:41 EDT
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.
Comment 5 Kevin Fenzi 2011-08-05 19:14:26 EDT
I'm pretty puzzled here too. ;( 

Perhaps lets move this over to coreutils and see if they have any ideas?
Comment 6 Kamil Dudka 2011-08-06 13:14:36 EDT
su from coreutils does not handle $DISPLAY and $XAUTHORITY any more, pam_xauth does.  See bug 622700 for details.
Comment 7 Ondrej Vasik 2011-08-07 03:55:55 EDT
Adding Tomas Mraz to CC ...
Comment 8 David A. De Graaf 2011-08-21 16:28:53 EDT
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.
Comment 9 Kamil Dudka 2011-08-21 17:32:40 EDT
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 ?
Comment 10 Tomas Mraz 2011-08-23 04:57:00 EDT
By using words like "massive pile of poo called pam" you clearly will not make the bug any higher priority. :)
Comment 11 Tomas Mraz 2011-08-23 05:27:56 EDT
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 ?
Comment 12 David A. De Graaf 2011-08-24 13:04:48 EDT
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.
Comment 13 Tomas Mraz 2011-08-24 15:15:01 EDT
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.
Comment 14 Fedora End Of Life 2012-08-07 16:18:12 EDT
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

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