bug#63082: [PATCH 04/17] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Freitag, dem 28.04.2023 um 10:26 -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.  Synchronizing both is not practical,
> as it can easily lead to slightly different <user-account> objects
> conflicting, again causing problems.
> 
> The compromise is to obsolete the 'group' field.  A group can still
> be configured via the 'user' field, which accepts a <user-account>
> object, with the limitation that the group should already exist.
Most services generate both an account and a group, whereas MPD would
be the odd one out here.  Defaulting to mpd:audio also has some minor
consequences when group permissions entail semantics, as this would
allow everyone in the audio group group access to mpd's stuff, which
seems needlessly permissive.  For this reason I think it makes sense to
allow users to specify a group, though it need not necessarily be via
the group field – for instance, we could make the user-accounts visible
to allow both specification of (list user group) and user alone,
deprecating the user and group fields in the process.  (Though we could
still provide read accessors to those.)

This still leaves us with the question of how to make audio work out of
the box.  IIRC using supplementary groups does not suffice, because the
service won't work then; do I actually recall that correctly?  


Cheers