http://bugzilla.suse.com/show_bug.cgi?id=1149037 http://bugzilla.suse.com/show_bug.cgi?id=1149037#c10 --- Comment #10 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.