systemd_create_users broken even more

systemd_create_users broken even more

[Chuck Wolber]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

When relying on useradd-staticids, this commit [1] made the problems that
this [2] bug causes, much worse. Prior to that commit we could predict with
surprising accuracy what the UID and GID would be for the very small number
of systemd-* accounts that were created (or simply patch the expected
UID/GID values in, but that never became necessary). After that commit, a
bunch of system accounts and groups get created with the wrong UID and/or
GID.

I suppose this is an opportunity to implement BZ9789. But since this issue
is so old it either means it was forgotten, or it is really hard in some
non-obvious way. Is there any insight available into which it is?

The solution seems pretty straight forward, so that pretty much guarantees
I am missing something important. In the systemd_create_users function
inherit extrausers, set the appropriate variables, call set_user_group
directly, and then remove set_user_group from ROOTFS_POSTPROCESS_COMMAND.

So where did I go wrong there?

Also, does it make sense to return from systemd_create_users early if
read-only-rootfs is *NOT* in IMAGE_FEATURES?

Thank you,

..Ch:W..

P.S. I think there is also a legitimate bug in systemd_create_users. I
noticed a few situations where it was trying to add a non-standard home
directory to the useradd command, but it was missing the --home-dir flag,
so the useradd command silently broke and did not fail the build.

1.
https://git.openembedded.org/openembedded-core/commit/?id=a94e622f222253c6646f1a1157f918d8aa586866
2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9789

-- 
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*

[-- Attachment #2: Type: text/html, Size: 2292 bytes --]

Re: [OE-core] systemd_create_users broken even more

[Richard Purdie]

On Fri, 2022-02-04 at 18:53 -0800, Chuck Wolber wrote:
> 
> When relying on useradd-staticids, this commit [1] made the problems that this
> [2] bug causes, much worse. Prior to that commit we could predict with
> surprising accuracy what the UID and GID would be for the very small number of
> systemd-* accounts that were created (or simply patch the expected UID/GID
> values in, but that never became necessary). After that commit, a bunch of
> system accounts and groups get created with the wrong UID and/or GID.
> 
> I suppose this is an opportunity to implement BZ9789. But since this issue is
> so old it either means it was forgotten, or it is really hard in some non-
> obvious way. Is there any insight available into which it is?

I don't think staticids are used that heavily and maybe not with systemd so I
suspect that it is just that nobody has spotted this issue. It doesn't sound too
hard to fix.

We're at a weird point with the project where many things were solved in the
past but the people and processes who solved those issues aren't there anymore.
We continue to make great progress in many areas but some issues are slipping
through the cracks. We do have new policies in place about tests and so on but
given the diverse uses of the project, there is only so much which can be
practically done with our current resourcing (from the community, membership and
otherwise).

> The solution seems pretty straight forward, so that pretty much guarantees I
> am missing something important. In the systemd_create_users function inherit
> extrausers, set the appropriate variables, call set_user_group directly, and
> then remove set_user_group from ROOTFS_POSTPROCESS_COMMAND.
> 
> So where did I go wrong there?
> 
> Also, does it make sense to return from systemd_create_users early if read-
> only-rootfs is *NOT* in IMAGE_FEATURES?

I'd imagine we'd prefer to do this "pre-processing" at build time if we can and
save it happening on every target device even if read-write.

Cheers,

Richard