[gentoo-user] persistent /run/* ownership/permissions

[gentoo-user] persistent /run/* ownership/permissions

[Grant]

I have to chown munin:nginx and chmod g+x on directory /run/munin/
after every reboot.  The munin list suggests altering the initscript
but is there a better way?

- Grant

Re: [gentoo-user] persistent /run/* ownership/permissions

[Alan McKinnon]

On 07/10/2015 18:27, Grant wrote:
> I have to chown munin:nginx and chmod g+x on directory /run/munin/
> after every reboot.  The munin list suggests altering the initscript
> but is there a better way?


There are ways, but I wouldn't call them better.

/run is often a tmpfs so the dir has to be mkdir'ed somehow after reboot
anyway. The initscript is the perfect place to do it. There's lots of
examples in most /etc/init.d, so I suggest submit a working patch to b.g.o.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] persistent /run/* ownership/permissions

[Grant]

>> I have to chown munin:nginx and chmod g+x on directory /run/munin/
>> after every reboot.  The munin list suggests altering the initscript
>> but is there a better way?
>
>
> There are ways, but I wouldn't call them better.
>
> /run is often a tmpfs so the dir has to be mkdir'ed somehow after reboot
> anyway. The initscript is the perfect place to do it. There's lots of
> examples in most /etc/init.d, so I suggest submit a working patch to b.g.o.


OK will do, thank you.

- Grant

[gentoo-user] Re: persistent /run/* ownership/permissions

[Martin Vaeth]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 07/10/2015 18:27, Grant wrote:
>> I have to chown munin:nginx and chmod g+x on directory /run/munin/
>> after every reboot.  The munin list suggests altering the initscript
>> but is there a better way?
>
> There are ways, but I wouldn't call them better.

The way to do it nowadays would be by placing a file with the content
d /run/munin 0775 munin nginx
into /usr/lib/tmpfiles.d (if done by the distribution) or into
/etc/tmpfiles.d (if this is only needed for your special setup).

> /run is often a tmpfs so the dir has to be mkdir'ed somehow after reboot
> anyway. The initscript is the perfect place to do it.

No, it is not the perfect place, because such a thing would
be strange to do if e.g. the initscript is restarted or
started only very late for some reasons (possibly hours
after the system start, if munin is not needed immediately.)
(OK, in /run it is not a security risk, but in world-writable
directories there exist symlink attacks or other bad things
if you create dirs/files too late and with a predictable name.
For dirs, it might be possible if you are *very* careful,
but the obvious "mkdir ...; chown ...; chmod ..." would be a
horrible security failure.)

Moreover, it is an init-system specific solution
while you can have a general solution.
Meanwhile, at least openrc and systemd both support the
tmpfiles.d subdirectories; I do not know the state of
other init-systems, but it is not hard to extend any
init-system of your choice to support these directories.
In any case, they are more compatible than a solution
which works with only *one* init-system.

Re: [gentoo-user] Re: persistent /run/* ownership/permissions

[Grant]

>>> I have to chown munin:nginx and chmod g+x on directory /run/munin/
>>> after every reboot.  The munin list suggests altering the initscript
>>> but is there a better way?
>>
>> There are ways, but I wouldn't call them better.
>
> The way to do it nowadays would be by placing a file with the content
> d /run/munin 0775 munin nginx
> into /usr/lib/tmpfiles.d (if done by the distribution) or into
> /etc/tmpfiles.d (if this is only needed for your special setup).


Will do.  Is that leading "d " supposed to be there?

Am I creating and editing /etc/tmpfiles.d or /etc/tmpfiles.d/anyfilename ?

- Grant


>> /run is often a tmpfs so the dir has to be mkdir'ed somehow after reboot
>> anyway. The initscript is the perfect place to do it.
>
> No, it is not the perfect place, because such a thing would
> be strange to do if e.g. the initscript is restarted or
> started only very late for some reasons (possibly hours
> after the system start, if munin is not needed immediately.)
> (OK, in /run it is not a security risk, but in world-writable
> directories there exist symlink attacks or other bad things
> if you create dirs/files too late and with a predictable name.
> For dirs, it might be possible if you are *very* careful,
> but the obvious "mkdir ...; chown ...; chmod ..." would be a
> horrible security failure.)
>
> Moreover, it is an init-system specific solution
> while you can have a general solution.
> Meanwhile, at least openrc and systemd both support the
> tmpfiles.d subdirectories; I do not know the state of
> other init-systems, but it is not hard to extend any
> init-system of your choice to support these directories.
> In any case, they are more compatible than a solution
> which works with only *one* init-system.

[gentoo-user] Re: persistent /run/* ownership/permissions

[Martin Vaeth]

Grant <emailgrant@gmail.com> wrote:
>>
>> The way to do it nowadays would be by placing a file with the content
>> d /run/munin 0775 munin nginx
>> into /usr/lib/tmpfiles.d (if done by the distribution) or into
>> /etc/tmpfiles.d (if this is only needed for your special setup).
>
> Will do.  Is that leading "d " supposed to be there?

Yes, see
http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html

> Am I creating and editing /etc/tmpfiles.d or /etc/tmpfiles.d/anyfilename ?

Actually /etc/tmpfiles.d/anyname.conf (the .conf is important),
see the above link.

Note that /etc/tmpfiles.d/anyname.conf
will "cancel" any existing /usr/lib/tmpfiles.d/anyname.conf:

This is so that packages can provide a default (in /usr/lib)
which you can override locally. (BTW: If that file is globally
needed, I suggest you reoport a bug to *upstream* to install an
appropriate file in /usr/lib/tmpfiles.d).

One can argue whether this mechanism is better than etc-update,
but it has some advantages: It works for all distributions,
and moreover, you can see immediately which modifications
you made locally (on the file level as well as with "diff"
on a finer level).