On Tue, 26.11.13 09:53, Colin Guthrie (gm...@colin.guthr.ie) wrote: > >> I'm proposing a simple goal: XDG_RUNTIME_DIR should always be that > >> matching the current uid. I can't think of any case where you'd > >> want it otherwise. > > > > That can't work. As the directory only exists when a real login session > > is around. su/sudo don't get their own login sessins, hence the dir > > doesn't necessarily exist and from the perspective of the code running > > in su/sudo the lifetime semantics of the dir wouldn't match any > > expections... > > Colin W's later patch did implement these semantics for the root user's > XDG_RUNTIME_DIR. It kept it around and didn't tidy it up. Doesn't this > solve the problem for the root user nicely (which is the primary > problem)?
I am pretty sure we shouldn't exclude the root user's XDG_RUNTIME_DIR from the usual clean-up logic. Also, as mentioned, if you want su-l/sudo-i work, then please add the "force-new-session=1" switch to pam_systemd, that I offered to merge. > But regardless, why doesn't this code create the dirs if they don't > exist anyway? Sure, this doesn't deal with lifetime problem (i.e. > knowing when to delete the dirs again) which is highlighted when su'ing > to another non-root user, but I think there was some talk in this thread > of adding some kind of refcounting here to make this behave better. We should avoid creating dirs we don't know are cleaned up again. logind is the component that cleans up those dirs, hence it should also create them. > Could logind not learn to track these "nested-mini-sessions"? They all That's what "force-new-session=1" would do. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
