bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Samstag, dem 06.05.2023 um 22:55 -0400 schrieb Maxim Cournoyer:
>> Hi!
>> 
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> 
>> > Am Freitag, dem 05.05.2023 um 14:29 -0400 schrieb Maxim Cournoyer:
>> > Didn't we agree in v2 that we want to address this on the account-
>> > service level?  Unless the rest of this series somehow depends on
>> > this patch, I'd rather delay it until we have a proper solution.
>> 
>> I think we agreed the idea to have <user-account> support <user-
>> group> objects for its group field was a good idea that should be
>> implemented, but I declined doing this new work as part of this
>> series :-).
> Indeed, that's how I understood it.  However, I also thought that
> addressing this issue in a later series means we can keep the current
> behaviour until that is done.

My focus on this series was making sure the configuration is easy(er) to
reason with and that it works out of the box for the most part.

>> > > Synchronizing both is not practical, as it can easily lead to
>> > > slightly different <user-account> objects conflicting, again
>> > > causing problems.
>> > It might not be practical to do so inside the service, but note how
>> > this has already become an effort in defensive programming.  There
>> > are easier ways to not make this a problem on the configuration
>> > level, namely by specifying the same group for both user and group
>> > fields.  As far as I see this is even the default state of being if
>> > the user is supplied as a string.
>> 
>> I really don't like the group information being duplicated in both
>> the user and a distinct field; it's an awkward API that raises more
>> questions than it provides answers, in my opinion (non-intuitive).
> And I agree that it's awkward, but I don't agree that this patch solves
> the underlying issue.

It puts the issue aside; if you can't configure a mismatched group, you
can't shoot yourself in the foot.

>> One of the reasons I came think this way is because a <user-group>
>> can differ by being a system group or not, which would make it easy
>> to introduce unexpected, subtle variants.
> Is that a serious issue, though?  Yes, two configuration files, one
> with (system? #t) and one without will produce different results in
> that GIDs are allocated differently, but the same applies to the user
> as well.  The only real issue I can think about here goes back to the
> handling of duplicate accounts and groups; and again, we both agree
> that those ought to be hard errors rather than warnings.

I think it's a serious issue because the permissions configured in the
start slot may be wrong, and the service could fail to run because of
it.

-- 
Thanks,
Maxim