[systemd-devel] SystemD, Gnome permission problems

[Lennart Poettering]

On Sun, 12.04.15 16:46, Elias Probst (mail at eliasprobst.eu) wrote:

> On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > I'm wondering if we should provide better per-user tmpfiles support.
> > For example, if we allowed a set of "user" tmpfiles, which would
> > be executed by the system instance, but would be considered relative to
> > the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home directory,
> > %t to XDG_RUNTIME_DIR, ...). We would execute that for every user.
> 
> Which makes me wonder again, why tmpfiles.d was never implemented in the
> way all other units are implemented.
> Currently, it's impossible to declare a dependency of a service upon a
> tmpdir, which feels out of line with the way things are usually handled
> in a systemd-based system.
> 
> For example:
> OpenVPN requires /run/openvpn/ to exist before being able to start.
> This leads to the following possible scenarios to make OpenVPN usable on
> a system where OpenVPN was just installed (and there was no reboot to
> trigger tmpfiles.d creation) yet:

It should just create the dir on its own. Invoking the mkdir() syscall
is hardly the most complex thing in the world. If it's really about
just this dir, it's certainly easier to make openvpn just invoke one
more syscall than to add a tmpfiles snippet an RPM scriplet invocation
and whatnot else. Also, it's much easier for everybody to grok, and
the thing will be a ton more robust...

> - creation of tmpfile directories is left to the application (again
> duplicated effort and the wrong place to do it, when there is a
> centralized mechanism for handling this properly)

I strongly disgaree. Invoking "mkdir()" is trivial, openvpn really
should do that. (unless it always runs unrpivileged, see below)

> are there any real technical/conceptual reasons, why tmpfiles.d handling
> wasn't implemented in the "systemd unit" way which would allow a service
> to depend on the correct state of one or more tmpfiles.d items, so on
> each service startup, the existence + state of the required directories
> would be verified and ensured.

We have RuntimeDirectory= as a native unit setting. However, it is
only really useful for daemons that run unprivileged all the time
(i.e. also use User= or so), and cannot create the directory on their
own. For all others: they really should create their runtime dirs on
their own. Don't bother with tmpfiles for no reason, please...

Lennart

-- 
Lennart Poettering, Red Hat