Comment # 10 on bug 1149037 from Aaron Puchert

(In reply to Jiri Bohac from comment #9)
> It will add a new radvd group and add the radvd user into the new group.
> Thus, fixing the problem.

Correct, if the radvd user already exists and is not member of the radvd group,
the "u" line will fail, but the "g" and "m" lines will at least add the group
and make radvd a member. At least that's my understanding. If the user doesn't
exist, for example because this is fresh install, then the "u" line will
succeed, and the "g" and "m" lines will fail, but that doesn't matter because
"u" created the group and used it as primary group.

> Yes, it will keep the user in whatever groups it used to be in.
> And I would consider that an acceptable upgrade behaviour. How do we know
> the system does not rely on radvd running with a specific group? Perhaps the
> admin changed some configfile permissions for whatever reason, we should not
> just change that because "the current default group is now different".

I have no skin in this game, I was just referring to this comment:

(In reply to Hans-Peter Jansen from comment #4)
> $ getent passwd radvd
> radvd:x:458:100:Router ADVertisement Daemon for:/var/lib/empty:/sbin/nologin
> 
> Hence, radvd's primary group is 100 still (users here). So, the whole
> sysuser-shadow seems to be missing the primary group concept. I would expect
> the radvd user to read:
> 
> radvd:x:458:452:Router ADVertisement Daemon for:/var/lib/empty:/sbin/nologin
> 
> and would accept the daemon membership with gritted teeth. But having it in
> users is not acceptable security-wise.

I'm not sure what the proper migration path is here, there seem to be arguments
for and against changing the existing primary group.