Hi! Liliana Marie Prikler <liliana.prik...@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
