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

[Lennart Poettering]

On Tue, 26.11.13 07:19, Martin Pitt (martin.pitt at ubuntu.com) wrote:

Heya,

> Lennart Poettering [2013-11-26  5:17 +0100]:
> > That can't work. As the directory only exists when a real login session
> > is around. su/sudo don't get their own login sessins, hence the dir
> > doesn't necessarily exist and from the perspective of the code running
> > in su/sudo the lifetime semantics of the dir wouldn't match any
> > expections...
> 
> Right, as long as they don't actually get one. I (and I think Colin)
> argued that "su -"/"pkexec" should (just like ssh localhost), as they
> run a full PAM stack which is like logging in. But let's agree to
> disagree at this point.

Disagree? I already offered that we add a new switch to pam_logind which
is only specified in the su-l/sudo-i PAM snippets which tells logind to
create an entirely new session, ignoring that the calling su is already
part of an existing session.

Let's say we call it "force-new-session=1" or so on the pam_systemd
configuration like, and we set that for /etc/pam.d/su-l and
/etc/pam.d/sudo-i but not in /etc/pam.d/su and /etc/pam.d/sudo. (Yes,
Debian/Ubuntu would have to gain separate config snippet for the two
cases to make this work, the way Fedora already has). Then, doing "su -"
would basically get you an entirely new session, only access to the TTY
you'd keep.

Doing this correctly is not entirely trivial though as these new
"limited sessions" should list the original tty device as their tty, but
probably not the seat/vtnr info, since they still should never get
access to any of the seats hardware...

Again, the offer stands: I'd be willing to merge such a patch. That way
the story is somewhat clear:

a) by default audit and logind session ids match
b) su/sudo will inherit almost all state from the parent with the
   exception of uid/gis, and get XDG_RUNTIME_DIR unset in order not to
   fuck things up 
c) su-l/sudo-i will get an almost entirely new session with no access to
   hardware but with access to the original TTY, and that's it.

Lennart

-- 
Lennart Poettering, Red Hat