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.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
