[systemd-devel] SystemD, Gnome permission problems

[Elias Probst]

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:

A#
- the package manager creates /run/openvpn as part of of its postinst
routine. This is duplicated effort and could easily go out of sync with
the definition in OpenVPN's tmpfiles.d configuration

B#
- the package manager calls "systemd-tmpfiles --create …" whenever a
tmpfiles.d configuration was installed. This might still be the most
straightforward way, but it could still happen that a user manually
deletes the directory and than at a later point attempts to start a
service depending on it

C#
- the user has to create /run/openvpn manually (I don't think I have to
outline why this is no "correct" solution)

D#
- 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)

E#
- the service unit contains something like "ExecPre=/bin/mkdir …". Again
duplicated effort and the wrong place to do it.


This leads me to the question:

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.

- Elias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150412/03f3542c/attachment.sig>