Bug 832074 – sys-apps/baselayout: portage user missing from the shadow file for sufficiently old systems

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Ellison Marks 2022-01-26 00:34:31 UTC]

So, I apparently have a system that was originally created with baselayout-2.2. In baselayout-2.3, the portage user was added to the shadow file, but since the ebuild (sensibly) does not overwrite the system's existing shadow file, the entry never made it into mine. Fast forward to now, and the new shadow ebuild runs pwck in it's postinst, in response to https://bugs.gentoo.org/829872, and complains. Perhaps baselayout should use the dispatch-conf system? As this hasn't caused me a problem in the ~6 years since installing 2.3, and the workaround was just copying the appropriate line into my shadow file, I'm marking this as minor.

Reproducible: Always

Steps to Reproduce:
1. have a system originally created with baselayout <= 2.2
2. upgrade from shadow 4.9-r4 to 4.11.1
Actual Results:  
 * Messages for package sys-apps/shadow-4.11.1:

 * Running 'pwck' returned errors. Please run it manually to fix any errors.

Expected Results:  
no messages.

[Comment 1 Sam James 2022-01-26 00:41:27 UTC]

If you run 'pwck' (as it says) it will actually fix it for you. No need to manually copy anything.

I don't think anybody has hit this on a new system, which makes it hard to find something to fix other than instructing people to run pwck (which is what we decided to do).

Stages and such will include acct-*/portage and things should be okay there. I'm not sure what fix we could apply in baselayout, especially given this can apply to different users anyway.

[Comment 2 Ellison Marks 2022-01-26 01:00:40 UTC]

It will offer to fix it, and if accepted, the generated line will be different than the one from baselayout.

Mentioning acct-*/portage, I actually tried re-merging those, just to see, but they didn't add the user to shadow.

My general thought was that, as baselayout changes, giving the user the option to incorporate changes (via dispatch-conf or some other mechanism) might be desirable. In this case it was portage in the shadow file, but theoretically any change might be good to incorporate.

[Comment 3 Mike Gilbert 2022-01-26 01:47:37 UTC]

> Perhaps baselayout should use the dispatch-conf system?

Not going to happen. The passwd and shadow files are not owned by any package, so config-protect doesn't apply. Triggering config-protect on every baselayout upgrade is not a good user experience.

> It will offer to fix it, and if accepted, the generated line will be different than the one from baselayout.

It does not need to be exactly equal to the line supplied in baselayout.

[Comment 4 Mike Gilbert 2022-01-26 01:53:21 UTC]

> Triggering config-protect on every baselayout upgrade is not a good user experience.

To expand on this: if we have baselayout own /etc/passwd, then every time baselayout is reinstalled, etc-update and distpatch-conf will prompt the user to remove any accounts that have been added to the passwd file by other means. That's just tedious and counter-productive.

I think having people to run pwck one time on old installs is not too much to ask.

[Comment 5 William Hubbs 2023-01-26 22:45:17 UTC]

The down side of triggering config-protect for baselayout upgrades is
that it makes it way to easy for a user to break their system.

I agree that it is better to have users run pwck if they hit this issue.