-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/26/2013 01:40 PM, Lennart Poettering wrote:
> On Fri, 26.07.13 11:01, Stephen Gallagher (sgallagh@xxxxxxxxxx)
> wrote:
>
>>
>> I'm CCing Lennart and Kay on the discussion about this. Creating
>> this symlink in the oddjob would be somewhat error-prone. I'd
>> rather that we ask logind to carry a patch just for F19 where the
>> creation of XDG_RUNTIME_DIR would include this symlink.
>
> Stephen, so Kay convinced me that it might be OK to handle su/sudo
> and su -l/sudo -i differently from the rest and accept that we have
> sessions that are started out of other sessions. This would mean
> you would get your new cred cache dir on "sudo -i", but not on
> "sudo". This would come with a number of uglinesses though, for
> example the session IDs (as returned by $XDG_SESSION_ID or listed
> by loginctl) would be in two different namespaces for "real logins"
> and for these su-l/sudo-i logins (the real ones would be named "1",
> "2", "3" and so on, the su-l/sudo-i ones "c1", "c2", "c3").
>
> If this is acceptable, then this should probably look like this:
>
> pam_systemd would need a new argument force-new=1 or so, which is
> passed for "su -l" and "sudo -i" but not otherwise. THis would be
> passed along CreateSession() to logind. When specified this would
> result in a session to be created independent of the existing one.
> Special care needs to be taken that this will not inherit anything
> like the seat or VT assignment or other session credentials from
> the original session.
>
> Then, then PAM krb module would pre-create XDG_RUNTIME_DIR via
> mkdir() when it initializes and logind would take this over later
> on. When the user finally logs out the dir would be removed by
> logind, as usual.
>
> I am not keen on this thing, because it introduces two different
> kinds of sessions ("real ones" and "child sessions", and detaches
> sessions from other definitions of sessions such as the audit one),
> but, well, if that's what it takes...
>
> Anyway, I'd to take a patch if that solution is OK for you.
>
> This doesn't require changes to the XDG_RUNTIME_DIR spec, since we
> just shift around what a session is, the existance of
> XDG_RUNTIME_DIR is then just effect of that.
>
First of all, Lennart: I really appreciate your willingness to meet
half-way and try to get this to work. It's a difficult problem with a
lot of edge-cases and no easy solutions. So thank you.
This would help us out on the 'su -l' and 'sudo -l' cases, but it
still potentially leaves us with two problems that I'm not sure how to
solve (without breaking the XDG_RUNTIME_DIR lifecycle definition).
1) https://bugzilla.redhat.com/show_bug.cgi?id=987792 has a problem
where a user is logging in through SSH with delegated Kerberos
credentials and is using AFS. After login is complete, his new session
is available with the credential cache dir in place, but unlike in
Fedora 18 and earlier, the KRB5CCNAME variable is not available to
other PAM modules prior to pam_systemd, meaning that his
pam_afs_session.so does not get set up correctly. It's presumed that
the reason for this is that SSH sees that it can't create the cache on
disk yet, so it waits and does so later.
2) We still need to consider use-cases where a cron job or other
long-running service needs to use credentials given to it by the user,
though they are no longer signed in. With the current approach, we
still need to be concerned that the /run/user/UID directory may just
cease to exist if there are no more active sessions on the machine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHyuH8ACgkQeiVVYja6o6Ns1QCfUvUeYSS+Bge+GTu7DHiagXh5
fRcAnj1nJgc0yMy7mllSRBeUP93gjr7z
=NPaz
-----END PGP SIGNATURE-----
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
