[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units
From:       Rich Freeman <rich0 () gentoo ! org>
Date:       2022-08-26 9:47:21
Message-ID: CAGfcS_mPKbrxN5n7pc5M=mu_shPbTmup66KKkVR6yK5UEzQNrA () mail ! gmail ! com
[Download RAW message or body]

On Fri, Aug 26, 2022 at 4:57 AM Florian Schmaus <flow@gentoo.org> wrote:
>
> While then can not be modified, settings made in /usr/lib/systemd/system
> can be overridden by the sysadmin by placing a file in /etc/systemd/system.
>
> I am not aware of a reason why a package manger should install systemd
> configuration files under /etc.
>

I'd say the biggest use case would be settings that typically require
modification that are needed at service launch time.  Think of
packages that stick stuff in /etc/conf.d for non-systemd settings.

An example of this can be found in sys-devel/distcc/files/distccd.service.conf

Sure, you could stick that in /usr, and then the user could copy it to
/etc (or use systemctl edit).  However, since it is something that is
basically intended to be edited you can argue that it makes more sense
to just stick it in /etc.  This also means that if a new setting gets
added the user will be made aware via config protection.  For a
drop-in that changes in /usr the user would receive no notice of this,
and the new settings would get merged with theirs or ignored depending
on how it was done.

For a distro override that wouldn't typically be modified, like
integrating one service with another that only service the local host,
then maybe /usr would make more sense.

Using systemctl edit is also a little awkward due to the way it
presents you with the original config at the bottom and you have to
copy the stuff you want to modify to the top.  I assume it lets you
copy comments as well, but it is a bit like opening up two editors and
copying from a skeleton file to a new file, vs just editing one in
place.  Well, except you aren't working between two files but editing
at two places in one file, so if your editor doesn't handle split
screen well you will scroll around a lot if the file is large.

I don't have very strong feelings about this either way, but I can
definitely see why things were done the way they're done.  I'm not
sure if there are any examples of fairly large drop-ins in /etc that
we install but I'd probably want to look at one before changing the
approach to see if it makes sense.

-- 
Rich

[prev in list] [next in list] [prev in thread] [next in thread]