Hi, On 14/11/13 13:57, Simon McVittie wrote: > libpam-systemd derives the XDG_RUNTIME_PATH from the "loginuid", which > was originally part of the audit framework. The loginuid was originally > intended to answer questions like "yes, I know this process is root, but > who is it really?" to provide an audit trail:
Thanks for the explanation. I wasn't aware of the rationale behind loginuid. The historical intention makes sense, but I don't get why logind should return XDG_RUNTIME_PATH based on this "really real uid" instead of the effective uid, since that's what's going to be used for permission control on the fs level. Am I missing something or do you mean to say this is a questionable decision? > (...) > Even after gdm daemonizes and re-parents to init, its loginuid remains. > That's sort of the point of loginuid. Again, makes sense, but doesn't explain why XDG_RUNTIME_PATH must use loginuid. If loginuid's main reason for existence is auditing, I should still be able to see that my gdm was started by a su'd user 1000, but I want it to get /run/user/<gdm's uid>, since that's the process effective uid. Or more importantly, it seems really unintuitive (to say the least) that a request for session creation for an *explicitly given* UID should create a runtime dir for a different uid. But again, I may be missing something obvious. > The same thing breaks many tools when run under su (e.g. see > <https://bugzilla.redhat.com/show_bug.cgi?id=753882>). There's some > recent discussion on that bug: Ubuntu developers have been hit badly by > it too. If I understand you (and mentioned bug log) correctly, I guess this bug should be reassigned (or at least cloned over) to systemd then? Cheers -- Leo "costela" Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
