On Mon, 30 Dec 2019 at 09:30:00 +0000, Niels Thykier wrote: > Jan Braun: > > XDG_RUNTIME_DIR is a systemd-ism, and due to the way it is specified, > > it's extremely unlikely to be implemented in other init systems.
XDG_RUNTIME_DIR is not implemented in the init system. It's implemented by systemd-logind (part of the systemd package and dependent on the systemd init system, but not actually part of the init system), and I think also by elogind (a fork that is not dependent on systemd). Before Ubuntu switched from Upstart to systemd, they had a standalone implementation of XDG_RUNTIME_DIR as a PAM module, which as far as I'm aware is entirely init-system-agnostic: https://launchpad.net/pam-xdg-support It no longer has an upstream maintainer now that Ubuntu has stopped using it, but if someone wants to resurrect it for non-systemd-booted systems, I'm sure that would be entirely possible. pam_xdg_support is a less careful implementation than the one in systemd-logind (giving users write access in /run lets them carry out a local denial of service by filling the filesystem, which systemd-logind avoids by allocating a separate small tmpfs per user) but that's a quality-of-implementation issue rather than a spec-compliance issue. If someone adopts pam_xdg_support, I would also suggest changing its XDG_RUNTIME_DIR path to use the numeric uid (like systemd-logind does) instead of the username - the equivalent of "/run/user/$(id -u)" instead of "/run/user/$(id -nu)". > > It also poses problems for tools like su/sudo. These tools should unset XDG_RUNTIME_DIR. By default, "su -" and sudo both do so. Plain su (without "-") does not, but plain su is problematic in various other ways (there are lots of environment variables that shouldn't be inherited across privilege boundaries). > The use case in debhelper is to setup an empty directory and point an > ENV variable at it to ensure we get a defined result *if* a tool uses > that ENV variable (namely, the tool gets a writeable empty directory for > the duration of the build). Yes. Specifically, the situation for which I wanted XDG_RUNTIME_DIR to be reset or unset by build infrastructure was this: * PAM integration in schroot invokes pam_systemd (or pam_xdg_support) which creates a directory on the host system and sets XDG_RUNTIME_DIR to its path * schroot enters a chroot * from the perspective of processes in the chroot, XDG_RUNTIME_DIR is set to a nonexistent directory * unit tests or code under test see that XDG_RUNTIME_DIR is set, and therefore assume they can/should use it (even if the code under test has a fallback path that would work equally well without) * unit tests fail Unsetting it would avoid most test failures, but some packages have non-essential features that require an XDG_RUNTIME_DIR; those features will be active on typical Debian installations, so ideally we would enable those features to be tested by build-time tests, for best test coverage of the code paths that a typical Debian installation will be using. smcv
