[systemd-devel] pam: Don't use loginuid [was: Re: Fix PAM module to not clobber XDG_RUNTIME_DIR with su]

[Martin Pitt]

Hello Colin,

Colin Guthrie [2013-11-14 10:28 +0100]:
> OK, I just tried this but I can't seem to make it work and prevent the
> XDG_* vars being set.
> 
> I applied the attached variation to my 208 build and then ran "pkexec
> /bin/bash" which also suffers from the same problems.
> 
> pkexec cleans out the environment quite well, but then pam_systemd
> re-injects these variables (I discussed this on IRC the other day with
> Colin Walters).
> 
> I would have thought that this should have fixed things.

I just tried here with pkexec, and I also do not get XDG_RUNTIME_DIR
any more there.

> I didn't get any joy from su or su - either (although I'd expect su to
> still have it set due to not cleaning the environment - is this a
> correct assumption?).

This only happens here if I explicitly specify su -m (but that's not a
very useful command to get a shell); by default su gets a clean
environment.

> The problem is that the pw_uid in this case is creating the session for
> my user, not the destination user (note the UID 603):
> 
> Nov 14 10:25:45 jimmy pkexec[14287]: pam_systemd(polkit-1:session):
> Asking logind to create session: uid=603 pid=14287 service=polkit-1
> type=unspecified class=background seat= vtnr=0 tty= display= remote=no
> remote_user= remote_host=
> Nov 14 10:25:45 jimmy pkexec[14287]: pam_systemd(polkit-1:session):
> Reply from logind: id=2 object_path=/org/freedesktop/login1/session/_32
> runtime_path=/run/user/603 session_fd=10 seat=seat0 vtnr=1

That's for pkexec'ing to root? I'd indeed expect uid=0 here. When I
run "pkexec /bin/bash" as my user (uid=1000) I get

Nov 14 16:55:31 donald pkexec: pam_systemd(polkit-1:session): Asking logind to create session: uid=0 pid=6269 service=polkit-1 type=unspecified class=background seat= vtnr=0 tty= display= remote=no remote_user= remote_host=
Nov 14 16:55:31 donald pkexec: pam_systemd(polkit-1:session): Reply from logind: id=c2 object_path=/org/freedesktop/login1/session/c2 runtime_path=/run/user/1000 session_fd=12 seat=seat0 vtnr=7
Nov 14 16:55:31 donald pkexec: pam_systemd(polkit-1:session): Runtime dir /run/user/1000 is not owned by the target uid 0, ignoring.

Same with su, when I e. g. do "su - joe" on my system, I get joe's
uid=1000. 

In my case audit_loginuid_from_pid() fails, so it gets the pw entry
from pam_get_user(). I suppose the difference is that for you it
succeeds, so you get the "wrong" UID. That's indeed the original title
of https://bugzilla.redhat.com/show_bug.cgi?id=753882, now I
understand comments 21 and others. But that's actually a separate
issue, as even in the "no auditd" case it does the wrong thing.

So option 1 is to update the patch to not rely on "uid", but instead
always get it from PAM. Option 2 is to never read it from loginuid, as
that's indeed not what one should be concerned about in a PAM module.

Attached patch is doing option 2. I suppose that's the one that
Lennart objects to, as he wants to keep as much of the original
session properties as possible. But it would be nice if you could at
least test it locally to make double-sure that this is the issue you
see?

Thanks!

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-pam-Don-t-use-loginuid.patch
Type: text/x-diff
Size: 2166 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20131114/22a0321a/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20131114/22a0321a/attachment.pgp>