[systemd-devel] SystemD, Gnome permission problems

[Kai Krakow]

Elias Probst <mail at eliasprobst.eu> schrieb:

> On 04/12/2015 05:47 PM, Kai Krakow wrote:
>> Elias Probst <mail at eliasprobst.eu> schrieb:
>> 
>>> 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.
>> 
>> F#
>> - the service file contains a RuntimeDirectory directive.
>> 
>> ;-)
>> 
> 
> Ha! Perfect! Thanks a lot for pointing this out.

You're welcome...

> My initial bugreport against Gentoo [1] regarding this issue is older
> than the implementation of RuntimeDirectory [2] - time for updating the
> bugreport + getting upstream (OpenVPN) involved to ship an updated
> service unit and get rid of their tmpfiles.d conf.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=462118
> [2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=e66cf1a3

A lot of packages should use this directive in Gentoo if I looked at 
/usr/lib/tmpfiles.d... There seem to be a lot of Gentoo-generated files 
(those without any comments) which could by migrated into the service file 
instead.

But, as Lennart pointed out, it would really be better if daemons created 
those directories by themselves. I'd not put that under the term "duplicated 
effort" - indeed you are having duplicated effort currently because every 
init system has to take care of creating those directories, sometimes even 
depending on configuration files, e.g. mysql configures this in the 
configuration file but also in the init file. As a sysadmin I have to take 
care to change all possible places. If, in this example, mysql would simply 
create this directory on its own, all would be good - no more duplicated 
effort. Well, OTOH mysql isn't started as root, thus it cannot create this 
directory. So, such services are dependent on duplicated work - but at least 
RuntimeDirectory is the right place to do it then.

I'd really prefer systemd's idea of services should create their runtime 
environment themselves on first start as complete as possible. Letting the 
package manager create all those empty runtime directories with .keep files 
so they become part of backups and do not become cleaned up, is really 
cumbersome and incomplete, and duplicate work because you have configuration 
in two places: the config file and the package manager. If I wanted to move 
runtime directories I'd have to configure the new directories but also 
create them or move them. Upon update, the package manager will recreate 
empty bogus directories. This should really go away.

-- 
Replies to list only preferred.