On 17/09/2015 10:01, tilt! wrote:
> Hi,
>
> On 09/17/2015 10:12 AM, Roger Leigh wrote:
> > On 11/09/2015 02:33, Daniel Reurich wrote:
> >> We could either use $USER_$SESSIONID or $USER/$SESSIONID to implement
> >> multiple sessions per user.
> >
> > This is definitely possible. It would probably need some thought on
> > how to determine which "session" you are in when cleaning them up via
> > PAM or whatever. Especially since it's not tied to the PAM session.
>
> Sorry, i still don't get it. What session?

The "session" terminology is ambiguous. There are several:

1) The PAM session

    Created and ended with pam_open_session/pam_close_session.  A PAM 
session is typically tied to the lifetime of a process.  For example 
login/su/sudo/ssh where the process handling auth will open the session, 
fork off the user shell/program, and then when the user process ends, 
will close the session.  It can also run in separate processes (schroot 
does this), but this is less typical.  For example:

    login
       pam_open_session() [ create xdg runtime dir / increment usage count ]
       fork()
          --> bash
       wait()
       pam_close_session() [ decrement usage count / delete xdg runtime 
dir ]

2) The XDG session

    The XDG spec only supports one existing at once due to their 
shortsightedness when writing the spec.  But more than one could in 
theory be supported.

Currently, the XDG session, including the runtime dir, can be shared by
multiple logins, i.e. separate PAM sessions. This means that when you
are running pam_close_session, the PAM module handling XDG cleanup needs
to be able to tie itself back to the XDG session to be able to clean it
up. This may be non-trivial, though if
pam_open_session/pam_close_session are running in the same process,
you'll have this information in the environment. If they run in
separate processes, it will become hard, but it's a case which needs
handling even if it only means "skip cleanup in this case". This is
where the "only one XDG session" limitation may have arisen--a cop-out!

So the outstanding question is: when my XDG cleanup PAM module is
invoked via pam_close_session, how do I
1) know it is safe to clean up the runtime dir
2) know the location of this runtime dir
In the logind case, it's handling the usage count for (1) and ignores
(2) since the location is hard-coded.

If every PAM session creates a new XDG session (i.e. a new runtime dir
per PAM session), then you could use the PID of the login process as the
unique session ID and use this in the runtime dir path. This avoids any
requirement to have a usage count, but at the expense of not sharing
session state with any other XDG session. [Not a big loss IMO, but
worth mentioning.]

Some of the other posts in the thread mentioned the awfulness of
logind/policykit/PAM and how we would be better off without them. While
I wouldn't argue over logind and policykit, PAM is essential and is used
for all login/auth on Debian systems--it must be supported. PAM has its
limitations, but it's generally a well thought-out system which does its
job well.


Regards,
Roger