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

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 26/11/13 04:17 did gyre and gimble:
> On Wed, 20.11.13 19:19, Colin Walters (walters at verbum.org) wrote:
> 
>>> So yeah, there your mix
>>> and match is broken: 
>>
>> I'm proposing a simple goal: XDG_RUNTIME_DIR should always be that
>> matching the current uid.  I can't think of any case where you'd
>> want it otherwise.
> 
> 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...


Colin W's later patch did implement these semantics for the root user's
XDG_RUNTIME_DIR. It kept it around and didn't tidy it up. Doesn't this
solve the problem for the root user nicely (which is the primary problem)?

[The rest of this mail is more "asking daft questions" than any kind of
complaint. I'm still struggling to see the problems of some proposed
solutions]

But regardless, why doesn't this code create the dirs if they don't
exist anyway? Sure, this doesn't deal with lifetime problem (i.e.
knowing when to delete the dirs again) which is highlighted when su'ing
to another non-root user, but I think there was some talk in this thread
of adding some kind of refcounting here to make this behave better.

Could logind not learn to track these "nested-mini-sessions"? They all
seem to go through the pam stack so what is the fundamental problem in
adding some kind of tracking to them? The statement that "As the
directory only exists when a real login session is around" appears to be
a self-imposed limitation inside logind. Surely we just create the
folder as needed - even on a su, track this mini-session. We don't need
to expose it as a real session - nor really track the processes
specifically (this isn't done now anyway), but just use it internally in
any "how many sessions are there for this user" checks when nuking the
runtime dir. This would solve the lifetime issue so it's possible to
tidy up the runtime dirs properly only when the last user really does
disappear.

I'm sure I'm missing something but all this just seems to be being made
more complicated than is necessary due to artificial problems that are
just a product of the current implementation! Is this a route forward or
is there a fundamental problem with that? I appreciate that not making
it a proper session and tracking the processes properly would maybe feel
nasty, but I'd still say it was a step in the right direction.

Perhaps it is a problem tracking when one of these nested sessions
actually logs out? Or perhaps the a problem would be doing something
like su[mini-session]+screen+detatch+logout[mini-session]? The
mini-session would be closed and the runtime dir cleaned up even tho'
processes in screen were still needing it. If this is a problem case
does screen need to be capable of registering it's own session (and I'd
say it needs to be a full session here such that it doesn't really die
when the containing session logs out). Would logind have to learn a new
mode for creating detachable sessions for things like screen or would
screen have to become setuid or something equally ugly here?


I'd really appreciate it if someone who groks all this stuff could write
up a "how it should be done" wiki page or something explaining what the
"best practices" would be to approach solutions to:

 1. starting a text shell as another user (either within a graphical env
or not (and whether to run GUI apps and play sound as the other user or
not).
 2. starting a new, detachable session e.g. screen as the current user
(possible done *after* 1. above).

These are things people do and I think there are legitimate reasons for
doing them - regardless, even if some of the cases only have
illegitimate reasons, we need to be able to fail gracefully and,
ideally, present a warning to the user. Making a stance and not
supporting certain (stupid) setups only works when you actually *tell*
the user that they can't do something and explain why and what the
alternative is.


Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/