'Twas brillig, and Lennart Poettering at 26/11/13 04:17 did gyre and gimble: > On Wed, 20.11.13 19:19, Colin Walters (walt...@verbum.org) wrote: > >>> So yeah, there your mix >>> and match is broken: >> >> 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)? [The rest of this mail is more "asking daft questions" than any kind of complaint. I'm still struggling to see the problems of some proposed solutions] 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. Could logind not learn to track these "nested-mini-sessions"? They all seem to go through the pam stack so what is the fundamental problem in adding some kind of tracking to them? The statement that "As the directory only exists when a real login session is around" appears to be a self-imposed limitation inside logind. Surely we just create the folder as needed - even on a su, track this mini-session. We don't need to expose it as a real session - nor really track the processes specifically (this isn't done now anyway), but just use it internally in any "how many sessions are there for this user" checks when nuking the runtime dir. This would solve the lifetime issue so it's possible to tidy up the runtime dirs properly only when the last user really does disappear. I'm sure I'm missing something but all this just seems to be being made more complicated than is necessary due to artificial problems that are just a product of the current implementation! Is this a route forward or is there a fundamental problem with that? I appreciate that not making it a proper session and tracking the processes properly would maybe feel nasty, but I'd still say it was a step in the right direction. Perhaps it is a problem tracking when one of these nested sessions actually logs out? Or perhaps the a problem would be doing something like su[mini-session]+screen+detatch+logout[mini-session]? The mini-session would be closed and the runtime dir cleaned up even tho' processes in screen were still needing it. If this is a problem case does screen need to be capable of registering it's own session (and I'd say it needs to be a full session here such that it doesn't really die when the containing session logs out). Would logind have to learn a new mode for creating detachable sessions for things like screen or would screen have to become setuid or something equally ugly here? I'd really appreciate it if someone who groks all this stuff could write up a "how it should be done" wiki page or something explaining what the "best practices" would be to approach solutions to: 1. starting a text shell as another user (either within a graphical env or not (and whether to run GUI apps and play sound as the other user or not). 2. starting a new, detachable session e.g. screen as the current user (possible done *after* 1. above). These are things people do and I think there are legitimate reasons for doing them - regardless, even if some of the cases only have illegitimate reasons, we need to be able to fail gracefully and, ideally, present a warning to the user. Making a stance and not supporting certain (stupid) setups only works when you actually *tell* the user that they can't do something and explain why and what the alternative is. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
