~/.profile stomps on /etc/gdm/Xsession $1 (session name)

Bug #61726 reported by Daniel Allen
8
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
New
Undecided
Unassigned

Bug Description

We were tracking a bug where customizations to a user's .profile would prevent them from logging in correctly. Initially we got a zenity warning dialogue "Xsession: unable to launch "noglob" X session --- "noglob" not found; falling back to default session."

Then, I determined that the users were unable to log into KDE, they could only log into gnome.

The answer turns out to be that /etc/gdm/Xsession relies on $1 containing the users' chosen session ('', '/usr/bin/startkde', etc) all the way through the script, though the many scripts it execs can set $1 as a side-effect (ie, ~/.profile, the /etc/X11/Xsession.d/ scripts). For example, the users have 'set noglob' as part of a script that's exec'd in their .profile. $1 is 'noglob' forevermore, overwriting the global from /etc/gdm/Xsession.

My workaround was to do the following in lines 105-114 of /etc/gdm/Xsession:

---
PREVIOUSPARAM=$1

# First read /etc/profile and .profile
test -f /etc/profile && . /etc/profile
test -f "$HOME/.profile" && . "$HOME/.profile"
# Second read /etc/xprofile and .xprofile for X specific setup
test -f /etc/xprofile && . /etc/xprofile
test -f "$HOME/.xprofile" && . "$HOME/.xprofile"

if [ -n $PREVIOUSPARAM ] ; then set $PREVIOUSPARAM ; fi
---

But a general solution of using a named parameter for the session instead of $1 would probably work better, and be less prone to side-effects. Thanks, -Daniel

Revision history for this message
Paul Holcomb (noptys) wrote :

I'm having a problem with ~/.profile and ~/.xprofile as well....

A user's ~/.profile or ~/.xprofile can set aliases or modify paths and
affect further execution of Xsession.

example:

--in run_parts() --

for F in $(ls $1); do
    if expr "$F" : '[[:alnum:]_-]\+$' > /dev/null 2>&1; then
      if [ -f "$1/$F" ]; then
        echo "$1/$F"

--

but if a user has set in their ~/.profile

alias ls='ls -CF'

then run_parts() breaks.

In my example, gnome-power-manager complained about the dbus service because /etc/X11/Xsession.d/75dbus_dbus-launch never ran

I propose moving the the ~/.profile and ~/.xprofile stanza later in
the script. Although a better solution might be to path-qualify all
the shell commands.

I've attached the patch for the change that worked for me.

Revision history for this message
Kees Cook (kees) wrote :

Upstream has fixed Xsession to have a path-qualified call to "ls" now.

Revision history for this message
Sebastien Bacher (seb128) wrote :

That looks like a duplicate from bug #48876

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.