lint: Verify /etc/{,g}shadow

[cgwalters]

We had a case where ublue developers hit this:

Mar 07 17:23:41 localhost systemd-sysusers[1022]: /etc/gshadow: Group "plocate" already exists.

And that becomes pretty fatal as other sysusers don't get added.

Add a bootc lint that verifies that /etc/gshadow doesn't have broken entries; we have code that cleans this up in rpm-ostree somewhere in https://github.com/coreos/rpm-ostree/tree/main/rust/src/nameservice or maybe the postprocess.

(Really we should have bootc container finalize|commit)

[cgwalters]

To briefly followup on this, it's a super messy situation.

The problem in a nutshell was this scenario:

• Going from an image that had users in /usr/lib/{passwd,group} aka nss-altfiles to one that didn't (because the first was run through https://github.com/hhd-dev/rechunk/ but the second wasn't)
• But /etc/{,g}shadow persisted from the previous deployment, with shadow entries for that plocate group for example
• systemd-sysusers chokes and dies on this
• Then critical users like e.g. gdm weren't added, meaning gdm didn't start

So this isn't something we can fix at bootc container lint time. At least not without increasing its scope. I could imagine supporting something like this:

FROM quay.io/exampleos/new as new
RUN --mount=type=bind,from=new,target=/run/newimage bootc container lint --to=new

or so where we could do a static analysis and warn about this type of upgrade scenario. Really we're kind of beyond what linting is and this should be a distinct tool.

But, that said in the end, we should be robust to this type of thing.

• First off, the shadow entries are just stubs and I really think systemd-sysusers should just allow the case where the shadow entry exists with ! for a password and that's going to be the new state too.
• Failing that though, we could ship a systemd unit...well, I'm not sure where, but something that would run Before=systemd-sysusers.service (or again maybe in the initramfs) that detects this situation and does its best to fix it

This one is actually kind of yet another special case of the generic uid/gid drift problem (ref #673 ) that just doesn't fall cleanly into bootc's currently designed architectural domain, but neither does it anything else's (it's not systemd's problem, nor shadow-utils problem, nor glibc etc.). I'm not excited about making it bootc's domain, but it may be the most practical thing to do.