Since doing fresh installs of Fedora 15 on two computers, I've found that the DISPLAY environment variable is not exported in some cases, despite being declared "exported".
This seems to be a clear violation of the EXPORT rules in /bin/bash. It is a severe handicap in a root window, since most of the GUI commands in the system-config-* group will not run.
The problem initially arose with the command /usr/bin/xterm -e /bin/su - which opens a new root window, prompting for the passwd. I found that system-config-network failed to open the customary GUI panel, but reverted to a semi-useless curses-based substitute. This was quickly traced to a missing DISPLAY definition in the root xterm.
However, this error occurs on only one of two laptops. Although the hardware is different - an IBM T30 vs an ASUS N10 - the packages installed differ only in that nvidia drives are installed on the ASUS. Both laptops usually run XFCE4; the DISPLAY error occurs only on the IBM T30.
To simplify the issue, and remove any potential security issues about switching to root, I used su only to switch user, and only to myself, ie: /bin/su - dad Passwd: No new xterm window was opened; I only changed user (to myself).
Before and after, I listed the exported variables: export -p > /tmp/exp.before and compared the lists.
To my surprise, there is a great number of variables that should have been exported, but were not. Here's the list of variable names that are NOT exported:
IBM T30 ASUS N10
DBUS_SESSION_BUS_ADDRESS= DBUS_SESSION_BUS_ADDRESS= DESKTOP_SESSION= DESKTOP_SESSION= DISPLAY= GLADE_CATALOG_PATH= GLADE_CATALOG_PATH= GLADE_MODULE_PATH= GLADE_MODULE_PATH= GLADE_PIXMAP_PATH= GLADE_PIXMAP_PATH= GNOME_KEYRING_CONTROL= GNOME_KEYRING_PID= GPG_AGENT_INFO= GPG_AGENT_INFO= LIBGLADE_MODULE_PATH= LIBGLADE_MODULE_PATH= OLDPWD= ORBIT_SOCKETDIR= SESSION_MANAGER= SESSION_MANAGER= SHLVL= SHLVL= SSH_AGENT_PID= SSH_AGENT_PID= SSH_AUTH_SOCK= SSH_AUTH_SOCK= WINDOWID= WINDOWID= WINDOWPATH= WINDOWPATH= XDG_CONFIG_DIRS= XDG_CONFIG_DIRS= XDG_DATA_DIRS= XDG_DATA_DIRS= XDG_MENU_PREFIX= XDG_MENU_PREFIX= XDG_SESSION_COOKIE= XDG_SESSION_COOKIE= XTERM_LOCALE= XTERM_LOCALE= XTERM_SHELL= XTERM_SHELL= XTERM_VERSION= XTERM_VERSION=
What's going on here? I would expect the exported environment variables to be identical in this experiment, but they are vastly different. Is someone playing fast and loose with the rules? In particular, why is DISPLAY not exported on the IBM T30, but is exported on the ASUS N10?
As a further experiment, I fired up gnome 3 on each machine and reran the comparison. To be brief, DISPLAY is exported properly on BOTH machines. There are many different exported variables between xfce4 and gnome, which is not surprising, but why should DISPLAY be treated differently?
I also tried different terminal emulators, Terminal, lxterminal, xfterm4, etc. I created a new user with a brand new $HOME. None of these had any effect.
Who can duplicate this failure to export? Why are variables, marked for export, not exported? Who can explain it? How can it be fixed?
I've filed BZ 722703 against xfce4, but a) I doubt that xfce4 is culpable, and b) The only responder seems to have run out of ideas.
Can anyone help?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/23/2011 02:17 PM, David A. De Graaf wrote:
Since doing fresh installs of Fedora 15 on two computers, I've found that the DISPLAY environment variable is not exported in some cases, despite being declared "exported".
This seems to be a clear violation of the EXPORT rules in /bin/bash. It is a severe handicap in a root window, since most of the GUI commands in the system-config-* group will not run.
The problem initially arose with the command /usr/bin/xterm -e /bin/su - which opens a new root window, prompting for the passwd. I found that system-config-network failed to open the customary GUI panel, but reverted to a semi-useless curses-based substitute. This was quickly traced to a missing DISPLAY definition in the root xterm.
However, this error occurs on only one of two laptops. Although the hardware is different - an IBM T30 vs an ASUS N10 - the packages installed differ only in that nvidia drives are installed on the ASUS. Both laptops usually run XFCE4; the DISPLAY error occurs only on the IBM T30.
To simplify the issue, and remove any potential security issues about switching to root, I used su only to switch user, and only to myself, ie: /bin/su - dad Passwd: No new xterm window was opened; I only changed user (to myself).
Before and after, I listed the exported variables: export -p > /tmp/exp.before and compared the lists.
To my surprise, there is a great number of variables that should have been exported, but were not. Here's the list of variable names that are NOT exported:
IBM T30 ASUS N10 DBUS_SESSION_BUS_ADDRESS= DBUS_SESSION_BUS_ADDRESS= DESKTOP_SESSION= DESKTOP_SESSION= DISPLAY= GLADE_CATALOG_PATH= GLADE_CATALOG_PATH= GLADE_MODULE_PATH= GLADE_MODULE_PATH= GLADE_PIXMAP_PATH= GLADE_PIXMAP_PATH= GNOME_KEYRING_CONTROL= GNOME_KEYRING_PID= GPG_AGENT_INFO= GPG_AGENT_INFO= LIBGLADE_MODULE_PATH= LIBGLADE_MODULE_PATH= OLDPWD= ORBIT_SOCKETDIR= SESSION_MANAGER= SESSION_MANAGER= SHLVL= SHLVL= SSH_AGENT_PID= SSH_AGENT_PID= SSH_AUTH_SOCK= SSH_AUTH_SOCK= WINDOWID= WINDOWID= WINDOWPATH= WINDOWPATH= XDG_CONFIG_DIRS= XDG_CONFIG_DIRS= XDG_DATA_DIRS= XDG_DATA_DIRS= XDG_MENU_PREFIX= XDG_MENU_PREFIX= XDG_SESSION_COOKIE= XDG_SESSION_COOKIE= XTERM_LOCALE= XTERM_LOCALE= XTERM_SHELL= XTERM_SHELL= XTERM_VERSION= XTERM_VERSION=What's going on here? I would expect the exported environment variables to be identical in this experiment, but they are vastly different. Is someone playing fast and loose with the rules? In particular, why is DISPLAY not exported on the IBM T30, but is exported on the ASUS N10?
As a further experiment, I fired up gnome 3 on each machine and reran the comparison. To be brief, DISPLAY is exported properly on BOTH machines. There are many different exported variables between xfce4 and gnome, which is not surprising, but why should DISPLAY be treated differently?
I also tried different terminal emulators, Terminal, lxterminal, xfterm4, etc. I created a new user with a brand new $HOME. None of these had any effect.
Who can duplicate this failure to export? Why are variables, marked for export, not exported? Who can explain it? How can it be fixed?
I've filed BZ 722703 against xfce4, but a) I doubt that xfce4 is culpable, and b) The only responder seems to have run out of ideas.
Can anyone help?
I would expect the list of variable names to be different with the root shell invoked with su -. When you use - or -l, things are set just like you had logged in as that user. Because of /etc/pam.d/su, DISPLAY and the "cookie" that lets you access X are carried over. You may want to compare these 2 files, and see if they are the same on both machines. You may also want to check /etc/pam.d/system-auth to see if they point to the same file, and the files are the same.
I am not sure, but it looks like a PAM problem to me.
Mikkel - --
Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
On Sat, Jul 23, 2011 at 02:31:57PM -0500, Mikkel L. Ellertson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/23/2011 02:17 PM, David A. De Graaf wrote:
Since doing fresh installs of Fedora 15 on two computers, I've found that the DISPLAY environment variable is not exported in some cases, despite being declared "exported".
This seems to be a clear violation of the EXPORT rules in /bin/bash. It is a severe handicap in a root window, since most of the GUI commands in the system-config-* group will not run. ... Can anyone help?
I would expect the list of variable names to be different with the root shell invoked with su -. When you use - or -l, things are set just like you had logged in as that user. Because of /etc/pam.d/su, DISPLAY and the "cookie" that lets you access X are carried over. You may want to compare these 2 files, and see if they are the same on both machines. You may also want to check /etc/pam.d/system-auth to see if they point to the same file, and the files are the same.
I am not sure, but it looks like a PAM problem to me.
Mikkel
Thank you Mikkel, for responding.
Precisely to avoid the complexities introduced by switching to root, I merely switched to my own userID with su - dad . I fully (sort-of) understand the significance of the - to "make the shell a login shell".
The original xterm window is a "login shell", or a somewhat distant descendant, since login occured in a console, and startxfce4 conspired to create that window, and several others. Therefore, it's environment should be based on, or inherited from, the original login shell, with obvious additions for X.
As I understand it (from the golden years of UNIX), what happens when I type /bin/su - dad is roughly this: - the shell forks, creating a child with all of the parent's exported environment but not the rest, and including stdin, stdout, and stderr. - the child runs login and checks the passwd for the new user - that user's startup scripts, ie, profile, bashrc, etc. are run, possible changing some of the environment - PATH, PS1, etc. - a bash prompt is presented
That's it!
Since the parent's user and the child's user are the same, I would expect the environment to be the same, or very similar.
They're not!
Some other process must be deliberately changing or undefining variables - such as DISPLAY, but also many others. I don't know who or why.
To answer your specific suggestions, all the files you mentioned, /etc/pam.d/su, /etc/pam.d/system-auth, and indeed all of /etc/pam.d/ are identical on both machines.
I really don't dig PAM, but given the congruence, it's hard to believe PAM is responsible.
On Sat, 2011-07-23 at 17:53 -0400, David A. De Graaf wrote:
As I understand it (from the golden years of UNIX), what happens when I type /bin/su - dad is roughly this:
- the shell forks, creating a child with all of the parent's exported environment but not the rest, and including stdin, stdout, and
stderr.
RTFM. According to the info page on su:
`-' `-l' `--login' Make the shell a login shell. This means the following. Unset all environment variables except `TERM', `HOME', and `SHELL' (which are set as described above), and `USER' and `LOGNAME' (which are set, even for the super-user, as described above), and set `PATH' to a compiled-in default value. Change to USER's home directory. Prepend `-' to the shell's name, intended to make it read its login startup file(s). When this option is given, /etc/pam.d/su-l PAM file is used instead of the default one.
IOW the DISPLAY environment variable will not be passed to the child shell in this case.
poc
-
David A. De Graaf -
Mikkel L. Ellertson -
Patrick O'Callaghan