[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 17:38, Gergely Nagy (algernon at balabit.hu) wrote:
>
>> > 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.
>
> Well, but there's no standard group so far that is only and exclusively
> used for log file access. There's "adm", but that's rather losely
> defined only, and kinda suggests by its name it actually opens up more
> than just access to log files?

Yep, correct. And that is why the default of creating a separate group
is a very good default.

> I mean, we are not adding n or n^2 or 2^n or so groups here. We are
> adding just 1. Maybe the better idea is to get "uucp" and "dip" removed
> from the current set of default groups (at least we on Fedora still have
> these nonsensical groups...)

I already removed any group that is not used, dip and uucp included. My
setup is *not* a default setup, hence my wish for a configurable group
for journal files.

> The group name is supposed to be an identifier, that helps people to
> know what things mean and by making this configruable you kinda break
> this point...

I don't see why it'd break that. Those who do not wish to change the
group, nothing would change. I'm fairly sure that the vast majority of
distributions wouldn't change it, either. So for, like 99% of the
userbase, making it configurable would mean no change at all. But for
that 1%, it'd be a tremendous help, even when 3rd party tools might
break due to it. If I'd find any, I'd submit a patch there too.

>> 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.
>
> This is a misconception. The "make install" call will actually set an
> ACL on the journal dir, to grant "adm" and "wheel" read access to all
> journal files, existing and future. This is even documented in
> systemd-journald.service(8). We recommend all distributions to set up
> these ACLs the same way.

That still requires me to add the group, though, and merely offers a
workaround. I'm not a fan of workarounds, neither a fan of additional
groups that do nothing for me (as said, on the systems where the new
group would be an issue, everyone who'd be in the journal's group if the
ACLs weren't there, would be in adm too - so separating the two in this
case is pointless).

> So, to underline this: "adm" continues to have access to the journal
> files by default. "systemd-journal" is just an additional group, that
> happens to own the files, and that is more minimal than wheel, adm or
> any other group.

The additional part is the one that bothers me most.

> Sorry, still not convinced...

No biggie, I'll continue patching systemd then until it gets very
boring, and will see if I can come up with a better argument for the
change at that point.

-- 
|8]