Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
My ~/.profile (I believe the default jessie one) was not being sourced as $PATH
was being set incorrectly
* What exactly did you do (or not do) that was effective (or
ineffective)?
I added trace to /etc/profile and ~/.profile (symlinked ~/.bash_profile to ~/.profile)
* What was the outcome of this action?
trace did not trigger
* What outcome did you expect instead?
I expected BOTH scripts to be executed at a GUI logon.
Looking back @ wheezy, I see work was done in /etc/gdm/Xsession. I took the relevant section
of that file and used it to create:
/etc/X11/Xsession.d/70fix_lightdm_gpv:
# GPV: 2-May-2015, lightdm + cinnamon forgets to source ANY profiles!!
# 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"
# Local Variables:
# mode: shell-script
# sh-indentation: 2
# indent-tabs-mode: nil
# End:
# vim:set ai et sts=2 sw=2 tw=80:
This caused both /etc/profile and ~/.profile to get executed and so the wheezy behaviour was restored.
The reported issue is not specific to cinnamon, so I'm reassigning parts of this to the lightdm package maintainers and the rest to the x11-common maintainers. not specified if it needs to be sourced by a X session, and it hasn't been the default in most Debian desktop managers. The documented way to add environment variables is using the ~/.xsessionrc to add them when starting the X session (see Xsession(5)), or /etc/environment and ~/.pam_environment to add them when login in via pam. Sadly, the pam file distributed in the lightdm package is not processing the /etc/environment and ~/.pam_environment file. Thus the reassignment of this bug to the lightdm package. Lightdm maintainers: please consider adding: auth required pam_env.so user_readenv=1 to the /etc/pam.d/lightdm conffile I'm not sure this is a good idea, but I forward this part to the x11-common package maintainers, so they decide whether it makes sense to add a Xsession.d script for this. Happy hacking,
Dear Maintainer, I was configuring a systemwide http proxy I've added http_proxy env variable to /etc/environment X application did not see the env variable, ssh sessions did I expected X to also see the env variable not sure if it's the same issue as the original bug report, anyway adding a line to /etc/pam.d/lightdm and /etc/pam.d/lightdm-autologin to do what the comment above pam_env.so line stated did fix the issue.
Hey. Anything new about this? It's clear that .profile and friends is *not* the right place to set the path. I would say however, that .xsessionrc isn't either, simply be because this would again be just for X, so users would need to set their PATH/etc. again at different locations. Doing this in PAM seems a proper way and adding user_readenv=1 seems to be not very invasive. I've also filed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989919 which asks the maintainers for login doing the same. Cheers, Chris.
Indeed. Because (I guess) the original #784158 message was about .profile as well. That happened later in the bug log and I might have missed it indeed. You can, but to be honest I'm unsure (and relecutant) about changing PAM configuration. I'd like to avoid breaking stuff in the authentication path so having a review of how correct these changes are would be nice. The bug asks for adding: to /etc/pam.d/login. I don't think 'auth' is the correct place since pam.d(5) says: I guess it'd fit more in: And the file already contains: So it'd be a matter of adding user_readenv=1. But to be honest, the PAM modifications for lightdm come from gdm3 package and I'm again reluctant to deviate from that, and GDM3 doesn't set user_readenv. Finally, the PAM configuration file has so I guess one could reconfigure pam to include user_readenv or something. Regards,
(sorry for re-sending, but seems the Debian BTS doesn't like my other mail address o.O) CCing pam maintainers for their opinion on whether this could be don in PAM's common-session config, for the benefit of all. Done. Uhm... isn't that what we have unstable for? I mean it wouldn't really help now, if I said, something works for me, cause PAM is rather complex and any other people could just see issues with it. But that change seems pretty non-invasive, doesn't it? I mean someone would have needed to create a user env file with broken settings to actually break something. So I'd say the "broken" setup is rather when someone created that file and it's not considered. Uhm... my understanding was that his is used by login(1) (only?)... i.e. if one log in via login on the Linux console. So it's needed there, too, for which I've reported #989919 a while ago. /etc/pam.d$ grep -R user_ sshd:session required pam_env.so user_readenv=1 envfile=/etc/default/locale polkit-1:session required pam_env.so readenv=1 user_readenv=0 polkit-1:session required pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0 do, except for: atd:auth required pam_env.so user_readenv=1 Yes, but that's for login(1) again, isn't it?! Well ideally *all* means of actually logging in should set this so that the user gets a uniform "experience". And I guess somewhere one needs to start ^^ Well would seem like an even better place... though also one where people even less likely to change something. Right now at least the situation is quite unfortunate, as there is no proper way (without manually changing the PAM config) for a user to set his PATH.... other than ugly hacks (.profile and .bash* are only sourced by Bourne-shell compatible shells respectively bash...) Thanks, Chris.
Hey. I should add, that there was: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611136 which is about a security hole that involved reading the user specific environment file. I couldn't find any in-depth analysis of that or some definite information on whether this was fixed or not. Cause in principle, if done right of course, it would sound strange if this could be used for an attack, when any user could also just set such vars in .profile/etc. . Also, e.g. Debian's /etc/pam.d/sshd would still read the user env file per default (so wouldn't that be affected from any security hole, too?) See perhaps also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989919#20 Thanks, Chris.