[Bug 61726] ~/.profile stomps on /etc/gdm/Xsession $1 (session name)

[Daniel Allen]

Public bug reported:

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

** Affects: gdm (Ubuntu)
     Importance: Untriaged
         Status: Unconfirmed

-- 
~/.profile stomps on /etc/gdm/Xsession $1 (session name)
https://launchpad.net/bugs/61726