Bug#784158: cinnamon: GUI logons with cinnamon + lightdm do not source either /etc/profile or ~/.profile

[graeme vetterlein]

Package: cinnamon
Version: 2.2.16-5
Severity: important
Tags: newcomer patch

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.


-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cinnamon depends on:
ii caribou 0.4.15-1
ii cinnamon-common 2.2.16-5
ii cinnamon-control-center 2.2.11-4
ii cinnamon-desktop-data 2.2.3-3
ii cinnamon-screensaver 2.2.4-6
ii cinnamon-session 2.2.2-5
ii cinnamon-settings-daemon 2.2.4.repack-7
ii cjs 2.2.2-2
ii cups-pk-helper 0.2.5-2+b1
ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1
ii gir1.2-accountsservice-1.0 0.6.37-3+b1
ii gir1.2-caribou-1.0 0.4.15-1
ii gir1.2-clutter-1.0 1.20.0-1
ii gir1.2-cmenu-3.0 2.2.0-3
ii gir1.2-cogl-1.0 1.18.2-3
ii gir1.2-gconf-2.0 3.2.6-3
ii gir1.2-gdkpixbuf-2.0 2.31.1-2+b1
ii gir1.2-gkbd-3.0 3.6.0-1
ii gir1.2-glib-2.0 1.42.0-2.2
ii gir1.2-gnomebluetooth-1.0 3.14.0-2
ii gir1.2-gnomedesktop-3.0 3.14.1-1
ii gir1.2-gtk-3.0 3.14.5-1
ii gir1.2-gtkclutter-1.0 1.6.0-1
ii gir1.2-javascriptcoregtk-3.0 2.4.8-2
ii gir1.2-meta-muffin-0.0 2.2.6-4
ii gir1.2-networkmanager-1.0 0.9.10.0-7
ii gir1.2-nmgtk-1.0 0.9.10.0-2
ii gir1.2-pango-1.0 1.36.8-3
ii gir1.2-polkit-1.0 0.105-8
ii gir1.2-soup-2.4 2.48.0-1
ii gir1.2-upowerglib-1.0 0.99.1-3.2
ii gir1.2-webkit-3.0 2.4.8-2
ii gkbd-capplet 3.6.0-1
ii gnome-icon-theme-symbolic 3.12.0-1
ii gnome-session-bin 3.14.0-2
ii gnome-settings-daemon 3.14.2-3
ii gnome-themes-standard 3.14.2.2-1
ii gsettings-desktop-schemas 3.14.1-1
ii libatk1.0-0 2.14.0-1
ii libc6 2.19-18
ii libcairo2 1.14.0-2.1
ii libcanberra0 0.30-2.1
ii libcinnamon-menu-3-0 2.2.0-3
ii libcjs0 2.2.2-2
ii libclutter-1.0-0 1.20.0-1
ii libcogl-pango20 1.18.2-3
ii libcogl-path20 1.18.2-3
ii libcogl20 1.18.2-3
ii libcroco3 0.6.8-3+b1
ii libdbus-glib-1-2 0.102-1
ii libgdk-pixbuf2.0-0 2.31.1-2+b1
ii libgirepository-1.0-1 1.42.0-2.2
ii libgl1-mesa-glx [libgl1] 10.3.2-1
ii libglib2.0-0 2.42.1-1
ii libgstreamer1.0-0 1.4.4-2
ii libgtk-3-0 3.14.5-1
ii libjs-jquery 1.7.2+dfsg-3.2
ii libmozjs185-1.0 1.8.5-1.0.0+dfsg-4.3
ii libmuffin0 2.2.6-4
ii libpango-1.0-0 1.36.8-3
ii libpangocairo-1.0-0 1.36.8-3
ii libpulse-mainloop-glib0 5.0-13
ii libpulse0 5.0-13
ii libstartup-notification0 0.12-4
ii libx11-6 2:1.6.2-3
ii libxfixes3 1:5.0.1-2+b2
ii libxml2 2.9.1+dfsg1-5
ii mesa-utils 8.2.0-1
ii multiarch-support 2.19-18
ii nemo 2.2.4-2
ii network-manager-gnome 0.9.10.0-2
ii policykit-1-gnome 0.105-2
ii python-dbus 1.2.0-2+b3
ii python-gconf 2.28.1+dfsg-1.1
ii python-gi-cairo 3.14.0-1
ii python-imaging 2.6.1-2
ii python-lxml 3.4.0-1
ii python-pam 0.4.2-13.1
ii python-pexpect 3.2-1
ii python-pyinotify 0.9.4-1
pn python:any <none>

Versions of packages cinnamon recommends:
ii cinnamon-l10n 2.2.4-1
ii gksu 2.0.2-9
ii gnome-terminal [x-terminal-emulator] 3.14.1-1
ii xterm [x-terminal-emulator] 312-2

Versions of packages cinnamon suggests:
pn python-opencv <none>

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Maximiliano Curia]

Control: reassign -1 lightdm 1.10.3-3
Control: clone -1 -2
Control: reassign -2 x11-common 1:7.7+7
Control: severity -1 normal
Control: retitle -1 Missing pam_env.so user_readenv=1 in the pam file
Control: severity -2 normal
Control: retitle -2 Xsession script to process /etc/profile and ~/.profile

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.

On 03/05/15 17:51, graeme vetterlein wrote:
> My ~/.profile (I believe the default jessie one) was not being sourced as $PATH
> was being set incorrectly

The ~/.profile file is intended to be sourced by a login shell session, it's
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 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"

> This caused both /etc/profile and ~/.profile to get executed and so the wheezy behaviour was restored.

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,
--
"Seek simplicity, and distrust it." -- Whitehead's Rule
Saludos /\/\ /\ >< `/

[Christoph Anton Mitterer]

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.

[Yves-Alexis Perez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, 2022-04-07 at 05:59 +0200, Christoph Anton Mitterer wrote:
> You've set wontfix on #672793 some longer time ago, but AFAIU, this was
> because of some user's request to have lightdm source .profile (which
> is IMO indeed plain wrong).

Indeed.

>
> Later on #784158 was forcemerged with these... (and thus also marked
> wontfix).
>
> Why so?

Because (I guess) the original #784158 message was about .profile as well.
>
> #784158 is a completely different request, namely to modify lightdm's
> PAM config to allow users to have an env file parsed.

That happened later in the bug log and I might have missed it indeed.

> May I split these up again?

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:

> auth required pam_env.so user_readenv=1

to /etc/pam.d/login.

I don't think 'auth' is the correct place since pam.d(5) says:

> auth
> this module type provides two aspects of authenticating the user.
> Firstly, it establishes that the user is who they claim to be, by
> instructing the application to prompt the user for a password or
> other means of identification. Secondly, the module can grant group
> membership or other privileges through its credential granting
> properties.
>


I guess it'd fit more in:

> session
> this module type is associated with doing things that need to be
> done for the user before/after they can be given service. Such
> things include the logging of information concerning the
> opening/closing of some data exchange with a user, mounting
> directories, etc.
>

And the file already contains:

> # Load environment from /etc/environment and ~/.pam_environment
> session required pam_env.so readenv=1
> session required pam_env.so readenv=1 envfile=/etc/default/locale

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

> @include common-session

so I guess one could reconfigure pam to include user_readenv or something.

Regards,
- --
Yves-Alexis
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmJOj10ACgkQ3rYcyPpX
RFtSFQgA5tRHtzYoo0vCcKgGFkHux4/5di3/kOLS1IbZzNS3IW7//lYOTQz5svJZ
VD3cllG7OvTxb7LgiQ9RjdsXURMYpxFPls4dj+B1a5t2Yy3Aj4THgGPSTTeExRx0
sMGncRkDMtfb13S+gA/Ojrj3zkk1TXFSWvGi3AJIqRjdnREsm/tR2DQyvflP3SG1
IOmSSWagWBxo7nG7JXf5gixfTdCMDVkPPJ5TTZuud04eOL1FHocjakjc6j5o/xMb
SsWZbx24eWja4AnVkksgVByUY3y3j7HoxKoomtpTWtqMosN+625qAKC1Mq2MDNxb
X/ITrn31x1JbOA6Qrx+xBV7TeOQf/A==
=/m/P
-----END PGP SIGNATURE-----

[Christoph Anton Mitterer]

(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.

On Thu, 2022-04-07 at 09:14 +0200, Yves-Alexis Perez wrote:
> > May I split these up again?
>
> You can

Done.

> 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.

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.

> The bug asks for adding:
>
> > auth      required pam_env.so user_readenv=1
>
> to /etc/pam.d/login.

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.

> I guess it'd fit more in:
>
> > session
> >     this module type is associated with doing things that need to
> > be
> >     done for the user before/after they can be given service. Such
> >     things include the logging of information concerning the
> >     opening/closing of some data exchange with a user, mounting
> >     directories, etc.

I guess so,... and that's also what most in my:
/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

> And the file already contains:
>
> > # Load environment from /etc/environment and ~/.pam_environment
> > session      required pam_env.so readenv=1
> > session      required pam_env.so readenv=1
> > envfile=/etc/default/locale
>
> So it'd be a matter of adding user_readenv=1.

Yes, but that's for login(1) again, isn't it?!

> 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.

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 ^^

> Finally, the PAM configuration file has
>
> > @include common-session
>
> so I guess one could reconfigure pam to include user_readenv or
> something.

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.

[Christoph Anton Mitterer]

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.