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

[Maxim Cournoyer]

Hi!

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

> Am Freitag, dem 05.05.2023 um 14:29 -0400 schrieb Maxim Cournoyer:
>> Prior to this change, there was a discrepancy where a user could have
>> disagreeing groups between the group and user fields (the user field
>> being a <user-account> record, which includes its primary group as a
>> string).  This could have caused problems because the USER's group
>> was being used to set the file permissions, while the GROUP name was
>> serialized to MPD's configuration, and MPD would use it to set the
>> group of its running process.  
> 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 :-).

>> 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).  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.

-- 
Thanks,
Maxim