-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/26/2013 02:52 PM, Lennart Poettering wrote: > On Fri, 26.07.13 14:32, Stephen Gallagher (sgallagh@xxxxxxxxxx) > wrote: > >> As Simo noted in the other thread, the availability of >> credentials outside the normal user session is an expectation of >> existing tools. The exposure here is significantly mitigated by >> the fact that Kerberos credentials are time-limited by the KDC. > > So, let me get this right: you want a host-specific tmpfs location > which is never automatically cleaned up, but is a private namespace > of the user (though the system sometimes writes to it), correct? > > That really sounds like a step backwards. Defining new runtime dirs > without immediately thinking about life-cycles is something we > really shouldn't do anymore. > > XDG_RUNTIME_DIRS was introduced just because we want a clear > life-cycle. > > Lennart > > PS: as a side note. what do you actually create in XDG_RUNTIME_DIR? > A subdirectory? You are aware of the inherent risks of sharing a > directory between system code and user code? It's extremely hard > to properly get a subdir created in such a dir without opening a > security hole. > Yes, we're creating a directory that will contain within it one or more file-based credential caches along with a special file that tells libkrb5 which one is the active default at a particular time. The actual cache directory is *never* created by system code. It's always generated by the libkrb5 in the user context. What *may* be created by the system is the enclosing directory. In the current situation, SSSD (as root) creates /run/user/UID and then libkrb5 creates /run/user/UID/krb5cc. What we're looking for is a more generic way to have a root process create the containing directory (either /run/user/UID or /run/kerberos/UID as appropriate). > PPS: if you give up on the unrestricted life-cycle and hence do > still want to use XDG_RUNTIME_DIR, and you don't want to pre-create > the dir on your own: you could just stick the cred cache into some > PAM context var instead of writing it to XDG_RUNTIME_DIR right > away, and then write it to the fs only at the very last step, long > after pam_systemd set it up for you. sshd could place its creds > there, and the PAM auth modules could add more into it, and then as > last step you just flush all that was collected to the dir. This > would be quite nice given that that way an aborted PAM sessions > setup could never leave the half setup pre-created dir around. > I talked about a similar approach on IRC today with Nalin and Ray Strode, but there's another edge-case problem there with pam_afs_session.so which will make a copy of the KRB5CCNAME env var during its execution (and consumes credentials from that location), so we can't just hold onto the creds and write them later, unfortunately. <halfline_laptop> maybe the credentials should be stuffed away in a MEMORY credential cache type tucked away in an AUTHTOK for PAM modules to use until pam_open_session time <halfline_laptop> when it can get serialized to XDG_RUNTIME_DIR <halfline_laptop> i guess "rewrite all the pam modules" isn't a very effective answer <sgallagh> Well, they wouldn't necessarily need to be rewritten <sgallagh> As long as the KRB5CCNAME env var is set properly, they should just be using that. <sgallagh> I'm not sure how clean a transition we could make in pam_open_session, though <halfline_laptop> yea i guess the problem is afs or whatever would still be looking in the old cache after the transition <sgallagh> exactly <halfline_laptop> so we'd need to make sure the afs session module told afs about the new location <halfline_laptop> -> back to rewriting all the pam modules -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHyx/AACgkQeiVVYja6o6PyXACeOyZVRPufgsqzsPTuaUvTMkQE cDkAn2ktmoB7SGXQNWICnYNkaYrU7LvE =T02s -----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
