/etc/gdm3/Xsession should not source ~/.profile
Submitted by Olin Shivers
Link to original bug (#745846)
Description
I suggest that it is a design error for gdm3's Xsession script to source ~/.profile. As the comments in the script header state, the script is not executed as a login shell; ~/.profile should only be sourced by a login shell.
Why is this a problem?
-
Consider .profile's that do things that interact with the tty. This will blow up. And this is a reasonable thing for .profile scripts to do.
-
Consider .profile's that exec to specific shells. Such as shells not on the central approved list of login shells permitted by chsh.
-
Consider a .profile that execs to some session daemons (e.g., ssh-agent, gpg-agent, or dbus-launch), with these agent's running the actual login shell as a child process. E.g.
exec dbus-launch --exit-with-session "$SHELL" exec ssh-agent "$SHELL" exec gpg-agent --daemon "$SHELL"
Such startup scripts will destroy the X session launch.
-
Less catastrophically, but still broken: suppose ~/.profile starts a session dbus with the perfectly reasonable
eval
dbus-launch --sh-syntax
The problem here is that after /etc/gdm3/Xsession sources ~/.profile, it then sources all the files in /etc/X11/Xsession.d. One of these files kicks off its own session dbus. Now you have two. The user cannot hack his .profile to check for an existing dbus daemon, because the .profile dbus is launched first.
The gdm3 designers have an obligation not to break .profile setups that were designed for classic, text-based login at the console or via ssh.
The point is that /etc/gdm3/Xsession is a session-launch program. It is not the "login shell." It should not be reading the login-shell init file.
Here is one way to patch this. Have gdm3's Xsession read some gdm3-specific startup file, such as ~/.gdm-profile. If you want to preserve the current, broken functionality, you can have Xsession read in ~/.profile only if ~/.gdm-profile does not exist. Thus, all users who have setups that currently rely upon the current, broken functionality keep getting the behavior upon which they rely, but other people can turn off the lossage simply by creating (a possibly empty) ~/.gdm-profile.
In general, however, I would argue that /etc/gdm3/Xsession shouldn't be doing this kind of stuff at all. It should be handled by ~/.xsession. Which is perfectly capable of sourcing ~/.profile if that is what the user wants.
Again, I have no objection to gdm3 being designed in such a way that the default is to source /etc/profile and ~/.profile, as long as there is a way to turn this off. -Olin
Version: 3.14.x