Jul 26 10:28:18 <sgallagh>	nalin: Could you please comment on simo's email to ipa-and-samba about /run/user (and/or join #sssd where we're discussing it)?
Jul 26 10:31:42 <simo>	sgallagh: wait sending to fedora-devel at david's request so he can be involved
Jul 26 10:31:52 <sgallagh>	ok
Jul 26 10:38:50 <sgallagh>	simo: http://pastebin.test.redhat.com/155347
Jul 26 10:39:03 <sgallagh>	Those are the ones I could locate quickly
Jul 26 13:20:12 <sgallagh>	nalin: I'm curious about your thoughts on simo's proposed solution to the /run/user catastrophe. Your opinion is particularly important, since it would involve a not-insignificant change to libkrb5 in Fedora/RHEL.
Jul 26 13:22:31 <nalin>	i'd be concerned about pulling in libdbus as a runtime dependency, as it really likes to keep the system bus connection open. you'd probably have to use a plain old bus-activated service rather than oddjob, because oddjobd doesn't get started by default
Jul 26 13:24:54 <halfline_laptop>	 /run/user catastrophe ?
Jul 26 13:25:17 <sgallagh>	halfline_laptop: It's lifecycle guarantee doesn't actually match our needs
Jul 26 13:25:27 <sgallagh>	So switching to it is causing all sorts of bugs
Jul 26 13:25:43 <sgallagh>	 /It's/its/
Jul 26 13:25:45 <halfline_laptop>	where's the impedance mismatch ?
Jul 26 13:26:03 <sgallagh>	It doesn't get created early enough and sometimes it's deleted while we still need it
Jul 26 13:26:41 <sgallagh>	halfline: So it's really not useful for anything that needs to be able to operate outside of a full login session.
Jul 26 13:27:19 <sgallagh>	And even in a full login session, we have bugs like https://bugzilla.redhat.com/show_bug.cgi?id=987792 where the environment isn't available to all the PAM modules that need it
Jul 26 13:28:03 <sgallagh>	nalin: I'm fine with us using a bus-activated service. I thought that's what oddjob was, but if not it's not a show-stopper.
Jul 26 13:28:32 <sgallagh>	I don't love the idea of opening maintaining the system bus connection either, but can't we just call dbus_connection_close() manually after we're done?
Jul 26 13:28:48 <sgallagh>	Or does D-Bus silently "optimize" that?
Jul 26 13:28:58 <nalin>	when i say "really likes" i mean "i think it aborts if you try to close it"
Jul 26 13:29:36 *	sgallagh gapes
Jul 26 13:30:02 <halfline_laptop>	sgallagh: oh so the issue is /run isn't mounted until pam_systemd runs
Jul 26 13:30:04 <sgallagh>	halfline_laptop: Do you happen to know if that's true^^?
Jul 26 13:30:07 <halfline_laptop>	pam_systemd is a session module
Jul 26 13:30:20 <halfline_laptop>	and pam_sssd wants to put credentials in place earlier than pam_systemd ?
Jul 26 13:30:30 <sgallagh>	No, /run is always there, but /run/user/UID is created by logind, not pam_systemd (I'm told)
Jul 26 13:30:39 <halfline_laptop>	libdbus will exit(1) if the bus connection is closed unless you tell it not to
Jul 26 13:31:03 <halfline_laptop>	so i wasn't be precise, when i said /run i meant XDG_RUNTIME_DIR
Jul 26 13:31:11 <halfline_laptop>	pam_systemd is what talks to logind
Jul 26 13:31:13 <sgallagh>	halfline_laptop: It's not just pam_sss, though. We need to deal with SSHD and forwarded GSSAPI credentials as well
Jul 26 13:31:18 <halfline_laptop>	it's what creates the logind session
Jul 26 13:31:21 <sgallagh>	With pam_sss, we're hacking around this already.
Jul 26 13:31:39 <nalin>	(not that we've given delegated creds a lot of thought)
Jul 26 13:32:33 <sgallagh>	halfline_laptop: The other problem is related to 'su' and 'sudo' which don't initiate a "full" session and so Lennart won't create XDG_RUNTIME_DIR for those processes.
Jul 26 13:32:48 <sgallagh>	nalin: Well, we know it doesn't work right now. That's a start.
Jul 26 13:33:14 <halfline_laptop>	i guess we don't register ssh sessions with logind ?
Jul 26 13:33:26 <nalin>	sgallagh: what's the expectation there when we're both authorized to the same local account and we both delegate creds while logging in to it?
Jul 26 13:33:35 <sgallagh>	I don't know how that works at all.
Jul 26 13:33:46 <nalin>	halfline_laptop: ssh is actually fine, there, since it's creating a new audit session. i suspect it's a timing thing
Jul 26 13:34:26 <nalin>	delegated creds fail to be stored before session is opened so that pam_afs_session can use them, location gets created during session open
Jul 26 13:34:35 <sgallagh>	nalin: Well, in the BZ I linked above, we realized that there's a problem where SSH won't set the KRB5CCNAME variable for the other PAM modules to use in that situation
Jul 26 13:34:45 <nalin>	yeah, but why?
Jul 26 13:34:56 <sgallagh>	Once you log in, you have your creds, but they weren't available to e.g. pam_afs_<mumble>.so
Jul 26 13:35:26 <sgallagh>	nalin: I can only make guesses without knowing the SSHD code
Jul 26 13:36:08 <nalin>	but you're sure the creds get stored? i can't tell from the report
Jul 26 13:36:26 <sgallagh>	Yeah, I spoke to ktdreyer about it
Jul 26 13:36:32 <sgallagh>	See the attached IRC log for more details
Jul 26 13:37:44 <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
Jul 26 13:37:59 <halfline_laptop>	when it can get serialized to XDG_RUNTIME_DIR
Jul 26 13:38:34 <halfline_laptop>	i guess "rewrite all the pam modules" isn't a very effective answer 
Jul 26 13:40:54 <sgallagh>	Well, they wouldn't necessarily need to be rewritten
Jul 26 13:41:13 <sgallagh>	As long as the KRB5CCNAME env var is set properly, they should just be using that.
Jul 26 13:41:25 <sgallagh>	I'm not sure how clean a transition we could make in pam_open_session, though
Jul 26 13:42:47 <halfline_laptop>	yea i guess the problem is afs or whatever would still be looking in the old cache after the transition
Jul 26 13:42:52 <sgallagh>	exactly
Jul 26 13:43:21 <halfline_laptop>	so we'd need to make sure the afs session module told afs about the new location
Jul 26 13:43:28 <halfline_laptop>	-> back to rewriting all the pam modules
Jul 26 13:43:58 <sgallagh>	It was worth proceeding down the path, if only to prove that it leads to sharks.
Jul 26 13:45:45 <sgallagh>	nalin: So I guess we're back to: how concerned are you about D-Bus? "libdbus will exit(1) if the bus connection is closed unless you tell it not to" sounds like we can tell it not to :)
Jul 26 13:46:37 <nalin>	hey, it's f20. go nuts
Jul 26 13:48:26 <nalin>	(to borrow your sharks metaphor, go ahead and chum the water)
Jul 26 13:48:58 <sgallagh>	Well, we can test it out in F20, but we need a solution for F19
Jul 26 13:49:15 <sgallagh>	Because it's broken in F19
Jul 26 13:49:35 <sgallagh>	(And it would probably be the decent thing to fix it there too)
Jul 26 13:50:02 <nalin>	once there's a known-good fix, sure
Jul 26 13:50:12 <sgallagh>	nalin, halfline_laptop, simo: Lennart just came back on the list with another option, but I suspect it still doesn't solve all of the cases we're concerned with.
Jul 26 13:50:26 <sgallagh>	Though I appreciate his willingness to meet us half-way.
Jul 26 13:50:52 <halfline_laptop>	which list?
Jul 26 13:50:56 <halfline_laptop>	sssd list? systemd list?
Jul 26 13:52:06 <nalin>	halfline_laptop: devel@lists.fedoraproject.org
Jul 26 13:52:12 <halfline_laptop>	oh f-d-l
Jul 26 13:52:20 <halfline_laptop>	actual development discussion on f-d-l ?!
Jul 26 13:52:39 <nalin>	i know, right?
Jul 26 13:52:43 <halfline_laptop>	simo++
Jul 26 13:53:39 <simo>	sgallagh: looks just patching one minor use case
Jul 26 13:53:50 <simo>	I think we should just get away from XDG_USER_DIR
Jul 26 13:54:24 <simo>	halfline_laptop: you have to thanks dwmw2, he asked to be involved in a mail thread I originally started internally
Jul 26 13:54:36 <simo>	but I am indeed happy to have brought it there in the end :)
Jul 26 13:57:03 <simo>	nalin: re dbus keep in mind we open it only when there is really the need to create the dir
Jul 26 13:57:15 <simo>	and given we do not delete it it should happen rarely
Jul 26 13:57:34 <simo>	if it happens in sssd also I do not care as we use a child process spawned on demand
Jul 26 13:57:50 <simo>	so the connection will die as soon as we have the dir and the ccache populated
Jul 26 13:57:59 <simo>	so all in all I think it is a minor issue
Jul 26 13:58:15 <simo>	nalin
Jul 26 13:58:18 <sgallagh>	simo: I've replied to Lennart on the list. Please correct me if my analysis was inaccurate or insufficient.
Jul 26 13:58:28 <nalin>	was sssd a place we were having problems?
Jul 26 13:58:37 <simo>	of course we could spawn a setuid bnary, but I think fork/exec in a library is worse than libdbus hanging to aconnection
Jul 26 13:58:40 <sgallagh>	nalin: originally, yes
Jul 26 13:59:03 <sgallagh>	We hacked up a solution where SSSD would pre-create the XDG_RUNTIME_DIR early and then cede control of it to systemd later in the stack
Jul 26 13:59:05 <simo>	nalin: yes we are working around issues in sssd by precreating the dir
Jul 26 13:59:07 <sgallagh>	But it wasn't sufficient
Jul 26 13:59:13 <simo>	but we shouldn't have to
Jul 26 14:00:06 <halfline_laptop>	users can configure their runtime dirs to linger after they log out
Jul 26 14:00:31 <simo>	halfline_laptop: you do not want the whole session to linger just for a cron job to run either
Jul 26 14:00:38 <simo>	halfline_laptop: but lingering is not the real problem
Jul 26 14:00:43 <simo>	it's first login the issue
Jul 26 14:00:52 <simo>	also we want this to work by default
Jul 26 14:01:02 <simo>	having to explain a user how to make it linger is already fail
Jul 26 14:01:40 <halfline_laptop>	we want cronjobs to be able to access a users kerberos credentials after they've logged out by default ?
Jul 26 14:04:36 <sgallagh>	halfline_laptop: I think that's probably a better user-experience at least.
Jul 26 14:05:02 <halfline_laptop>	hmm i'd expect my credentials to go away when i sign out
Jul 26 14:05:37 <halfline_laptop>	though i guess there is the whole offline login thing to think about
Jul 26 14:05:43 <sgallagh>	Well, Kerberos credentials have a finite life as well
Jul 26 14:06:15 <sgallagh>	Also, we're storing these credentials on tmpfs by default, so they're not going to survive a powerdown/laptop theft.
Jul 26 14:07:24 <sgallagh>	So this is only an exposure on a system that stays up for a long time, and only for a specified duration.
Jul 26 14:07:58 <sgallagh>	It's easy for the KDC administrator to then set policies on how long the tickets can last to minimize that.
Jul 26 14:08:29 <sgallagh>	(i.e. shorter lifetimes, disallow renewals without re-entering credentials, etc.)
Jul 26 14:09:14 <halfline_laptop>	well if you want credentials to out last a user then XDG_RUNTIME_DIR is definitely the wrong place for it
Jul 26 14:09:14 <sgallagh>	I think in server situations, wanting to be able to run stuff when you're not logged in would tend towards being the rule rather than the exception
Jul 26 14:09:29 <sgallagh>	Yeah, that's the conclusion I'm coming to as well
Jul 26 14:14:49 <simo>	halfline_laptop: simple example: cron job that starts every 10 min to do something on NFS
Jul 26 14:15:01 <simo>	halfline_laptop: you do not want to have it stop working 10 min after you log out
Jul 26 14:15:22 <simo>	or even if you give it a keytab you do not want it to have to get a new ticket every 10 min when the ccache duration is 8 hours