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

Bug #61726 reported by Daniel Allen on 2006-09-21
8
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
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

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.

Kees Cook (kees) wrote :

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

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  Edit
Everyone can see this information.

Other bug subscribers