[systemd-devel] Arbitrary restrictions (e.g. for RuntimeDirectory)
Andrei Borzenkov
arvidjaar at gmail.com
Thu May 9 14:54:42 UTC 2019
09.05.2019 13:22, Ulrich Windl пишет:
> Hi!
>
> I had to subscribe to this list, even though I'm no systemd fan. Still I'll have to deal with it as the distribution we use switched to systemd...
>
> I'm porting my LSB code to systemd, and I'm having some trouble. Cause of the trouble (and possible reason for systemd's unpopularity) seems to be rather arbitrary restrictions without reasoning (which is completely against the GNU spirit of seeking for limitless software).
>
> To be concrete: Why isn't it allowed to use an absolute path for RuntimeDirectory,
Wild guess - RuntimeDirectory is about security and permitting arbitrary
path here rather contradicts this goal.
> and wy isn't even a relative path allowed? In my case I have a multi-instance daemon, where the instances can be zero to many. To avoid namespace conflicts, I created a /var/run/<my_pkg> directroy
systemd does it for you.
> where all the instances put their stuff (in separate directories each)
>
> Trying "RuntimeDirectory=<my_pkg>/%i" inside <my_pkg>@.service isn't "accepted". Still the instances start, can be checked and stopped, but there is a message when stopped saying
> systemd[1]: [/usr/lib/systemd/system/<my_pkg>@.service:12] Runtime directory is not valid, ignoring assignment: <my_pkg>/%i
This works here; use of multilevel paths is even documented; granted,
ability to use specifiers is not that obvious from manual page.
>
> As "mkdir -p" exists for at least 25 years, I wonder what this is all about.
>
I tentatively suspect that being less aggressive may actually help ...
> Despite of that I'm missing a "systemctl validate ..." command. That way I wouldn't need to execute start, status, stop, just to find out that some settings are rejected.
>
> Regards,
> Ulrich
>
>
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
More information about the systemd-devel
mailing list