[systemd-devel] [PATCH] journald: Make the group that owns journal files configurable

[Gergely Nagy]

Lennart Poettering <lennart at poettering.net> writes:

> On Thu, 07.03.13 16:41, Gergely Nagy (algernon at balabit.hu) wrote:
>
>> While a separate group to own the journal files is desirable, which
>> group it is should be tweakable (to the point where it can be set to
>> an existing group, like adm, for systems where that makes sense).
>> 
>> To this end, this patch introduces a --with-journal-group=GROUP option
>> to configure, and uses the supplied value (or systemd-journal, if none
>> specified) as the dedicated group.
>
> I don't think this is really desirable. This group is something external
> packages should be able to make use of and rely on, and it would be
> suboptimal if you'd have to configure this group everywhere manually.

The main reason behind the patch is that I already have systems
installed where logfiles belong to a dedicated group, and when I'll be
migrating those to systemd & journal, I'd like to keep the groups and
not introduce yet another one that does the same thing. There's already
more groups on my systems than I need, I'd like to trim them down, not
introduce new ones.

It *can* be considered a corner case, as I also have very few, and only
trusted users, so the adm group was a perfect fit for my use case.

> Note that your patch already ran into one instance of the problem of
> making this configureable: systemd-journal-gatewayd.service refers to
> this group in SupplementaryGroups= in order to get access to the journal
> files, which your patch didn't update. So, you see, it already made
> BOOM! once to have this configurable, because it was too hard to keep
> things in sync.

Yeah, my bad. Caught that a few moments after sending the patch, and
started to investigate if I missed anything else too. :(

That's what I get for "submit first, test later".

> So, I am very conservative on making this configurable, but hey, I can
> be convinced, so can you make a really good case for this?

Apart from the case I outlined above, all other reasons I'd have boil
down to convenience. Similarly how the 'tty' group's ID is configurable,
the journal group being similarly configurable would make it much easier
downstream to adapt the journal to an existing environment.

Sure, I could patch it, but... I don't like patching, it makes it harder
to follow upstream in the long run. With a configure flag, I can just
update my sources and rebuild. If I have to patch, I need to fix any
conflicts, or even at best, refresh patches so they apply without
fuzz. Will even need to pay attention to any new places the hard-coded
group gets introduced aswell, and update the patch. That's a tedious
job, one I'd rather avoid.

Making it configurable would allow me to follow systemd more
closely. Perhaps a warning can be added to the configure switch that
changing it from the default may very well break external tools, or even
hide the option (if that is possible with autoconf).

I do understand your concern, and wholeheartedly agree that it does bear
some risk, but with clear documentation or with a hidden configure flag,
I think those risks are negligible, while the benefits are great for
those of us who can upgrade software, but not change policy.

I mean, if I have to add the users I have in the adm group to
systemd-journal aswell, that means adding the group to LDAP, then
updating the users too... ick. Too much work for no real gain for me.

-- 
|8]