On Fri, Sep 11, 2015 at 11:23:38AM +0200, tilt! wrote: > Unadressed remains the lifecycle of $XDG_RUNTIME_DIR, specifically: > > * When is $XDG_RUNTIME_PREFIX created? > > If $XDG_RUNTIME_PREFIX hosts every user's runtime directory, > it may not be created with ownership of the user, so to do > this alone: > > # as user: > > mkdir -p -m 700 "$XDG_RUNTIME_DIR" # wrong! > > is the wrong approach, the prefix has to be created owned by > root, readable by all, and subdirectories have to be created > owned by user, read/writeable for user only. > > # as root: > > mkdir -p -m 755 "$XDG_RUNTIME_PREFIX" > > Currently my best guess is that this should be performed > at system startup.
Yes. > * When is $XDG_RUNTIME_DIR created? > > If the prefix is created like described above, it requires > root permissions to create the per-user directory: > > # as root: > > # let $uid be the user ID of the affected user; > # let $xdg:runtime_dir be the requested runtime directory: > > if ! test -d "$xdg_runtime_dir" ; then > mkdir -p -m 700 "$xdg_runtime_dir" > chown $uid:$(id -g $uid) "$xdg_runtime_dir" > fi > > Currently my best guess is that this should be performed > everytime the user starts an X session (it's an X thing > after all, right), but Xsession.d is executed as the > user, not root. Changing into the user ID is a thing of > the display manager, there's no general way to hook in. > Remains PAM. Probably. PAM would probably work well. If I were implementing it (note: I'm the sort of guy who doesn't use PAM, or logind, or policykit...), I'd use a setuid helper that will construct a path based on a fixed prefix, the user ID, and optionally a six-character random string (ie, the "-n" option appends _XXXXXX and calls mktemp). It will then create this directory, change the owner and permissions, and print it to stdout, so that you could do: XDG_RUNTIME_DIR=`mkxdgrt -n` if you want a new session. This helper would be called from the login or X startup scripts. Alternately, you could theoretically create a new mount namespace for each user (at login, check if there are any processes with the target uid, and if so join their namespace). If you created a new namespace, mount some sort of RAM-backed filesystem with a size limit at XDG_RUNTIME_DIR; its contents will go away with the last user process. > * When is $XDG_RUNTIME_DIR deleted? > > If the per-user runtime directory is created as i described > above, user permissions suffice to delete it, so it was > sufficent to > > # as user: > > rm -rf "$XDG_RUNTIME_DIR" > > Unfortunately i am in the dark over what it means that a > user has "fully logged out". Does it mean that no processes > run with the user's identity anymore? That the user has no > X session running? That the user has no PAM session running? > And, if any of these mean that the user has "fully logged > out", how to hook into such an event and perform the code > suggested above? Officially, when the last process owned by the user exits. (This is the main advantage of the mount-namespace based approach.) In practice, *I* would be fine with "at shutdown, and make sure it's gone at boot." HTH, Isaac Dunham _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
