Bug 1149037

Sounds like an upgrade problem: the sysusers file only contains the user, not a radvd group. As the user in upgrade case already exists, no group is created.

Migration from old user setup to new one (with extra radvd grop) is missing.

fixed here: https://build.opensuse.org/request/show/742196

Well, the proposed fix from Jiri is not enough, because:

( 49/157) Installing: radvd-2.18-2.1.x86_64 ...........................................................................................................[error]
Installation of radvd-2.18-2.1.x86_64 failed:
Error: Subprocess failed. Error: RPM failed: useradd -r -s /sbin/nologin -c "Router ADVertisement Daemon for IPv6" -U -d /var/lib/empty radvd
usermod -a -G radvd radvd
usermod: group 'radvd' does not exist
error: %prein(radvd-2.18-2.1.x86_64) scriptlet failed, exit status 6
error: radvd-2.18-2.1.x86_64: install failed
error: radvd-2.18-1.1.x86_64: erase skipped

I do have a radvd user:
$ getent passwd radvd
radvd:x:458:100:Router ADVertisement Daemon for:/var/lib/empty:/sbin/nologin

but no radvd group:
$ getent group radvd
$

Since the whole sysuser-shadow package comes with zero documentation, it's not easy to spot the correct fix. system-user-radvd.conf might be missing a 

g radvd 

line, but who knows? The other comments are a little disturbing. They seem to imply, a radvd group exists, but that's not true for TW 20191027 at least.

Another fun fact: after adding the missing group manually:

$ groupadd -r radvd

and rerunning the zypper dup:

( 20/110) Installing: radvd-2.18-2.1.x86_64 ............................................................................................................[done]
Additional rpm output:
useradd -r -s /sbin/nologin -c "Router ADVertisement Daemon for IPv6" -g radvd -d /var/lib/empty radvd
usermod -a -G radvd radvd
usermod -a -G daemon radvd
Updating /etc/sysconfig/radvd ...

The result is still less than optimal:

$ getent group radvd
radvd:x:452:radvd

$ getent group daemon
daemon:x:2:radvd

$ 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 agree, I don't think this was the right fix: "m" lines add secondary groups, but here the primary group is wrong, and the right primary group doesn't exist.

I don't think this can be fixed in sysusers.d, because it's careful not to overwrite anything. The group must probably be fixed manually in %post.

(In reply to Hans-Peter Jansen from comment #3)
> Since the whole sysuser-shadow package comes with zero documentation, it's
> not easy to spot the correct fix.

man sysusers.d

(In reply to Hans-Peter Jansen from comment #4)
> Hence, radvd's primary group is 100 still (users here). So, the whole
> sysuser-shadow seems to be missing the primary group concept.

I don't think so, it just doesn't change any existing users or groups. See section IDEMPOTENCE in the man page: "Note that systemd-sysusers will do nothing if the specified users or groups already exist".

*** Bug 1156388 has been marked as a duplicate of this bug. ***

Sorry for the trouble with the previous fix.


> Since the whole sysuser-shadow package comes with zero documentation, it's
> not easy to spot the correct fix. 

Indeed.

I actually tried the previous fix and it worked for me. But I did not try installing the package, I just edited the system-user-radvd.conf file and observed that the correct group and user have been created on boot. UI trusted that the same would happen in the rpm script, but obviously it behaves differently! 
 
> system-user-radvd.conf might be missing a
> g radvd

This seems to fix it. Thanks!
I created a new submitrequest: 748094

(In reply to Jiri Bohac from comment #7)
> > Since the whole sysuser-shadow package comes with zero documentation, it's
> > not easy to spot the correct fix. 
> 
> Indeed.

https://www.freedesktop.org/software/systemd/man/sysusers.d.html

> > system-user-radvd.conf might be missing a
> > g radvd
> 
> This seems to fix it. Thanks!
> I created a new submitrequest: 748094

I don't think so: sysusers.d doesn't overwrite existing users, so if the existing user has a primary group 100, the update won't change anything. Neither "m radvd radvd" nor "g radvd" should be there, instead this needs to happen:

(In reply to Thorsten Kukuk from comment #1)
> Migration from old user setup to new one (with extra radvd grop) is missing.

sysusers.d cannot do this by design.

(In reply to Aaron Puchert from comment #8)
> (In reply to Jiri Bohac from comment #7)
> > > Since the whole sysuser-shadow package comes with zero documentation, it's
> > > not easy to spot the correct fix. 
> > 
> > Indeed.
> 
> https://www.freedesktop.org/software/systemd/man/sysusers.d.html

good; trouble is the rpm prein script does not invoke the documented systemd sysusers tool, instead it uses some weird sysusers2shadow tool. It's rpm description  says "
This package contians a tool, which expects as input a sysusers.d
configuration file and uses the shadow suite to create the users
and groups from it like systemd-sysusers would do.
"

This is clearly not true; I tested my first patch and systemd handled it correctly. I had no idea it would fail during install because another tool is used.

Why is that, I don't know, I think it's a really bad idea to have two tools doing almost the same thing but not quite. Why don't the rpm pacros invoke the proper systemd tooling that is then used on every boot?


> > > system-user-radvd.conf might be missing a
> > > g radvd
> > 
> > This seems to fix it. Thanks!
> > I created a new submitrequest: 748094
> 
> I don't think so: sysusers.d doesn't overwrite existing users, so if the
> existing user has a primary group 100, the update won't change anything.
> Neither "m radvd radvd" nor "g radvd" should be there, instead this needs to
> happen:

It will add a new radvd group and add the radvd user into the new group. Thus, fixing the problem.

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

But I'm not going to push against any working alternative solutions. Feel free to submit your own. So far I'm happy with this one.

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

I consider this fixed by SR 748094