[gentoo-dev] Modification proposal for user/group creation when ROOT!="/"

[gentoo-dev] Modification proposal for user/group creation when ROOT!="/"

[Farid BENAMROUCHE]

Hi all,

Currently there is an old known limitation when using ROOT= option to install a package in a folder: user/groups are created in the host filesystem, not the target root filesystem.

So I've pushed some modifications to the upstream shadow repo.
Basically, I've added a --prefix option to user{add,mod,del} and group{add,mod,del}
This option does the same as --root option, but whithout a chroot (so compatible when cross compiling)
You can see more details (and the limitation of my implementation) in the shadow github repo:
https://github.com/shadow-maint/shadow/issues/18


Now, for the gentoo part, I do have a working solution that I've pushed in the following bugzilla:
https://bugs.gentoo.org/show_bug.cgi?id=541406

A new user.eclass file with modified enewuser,enewgroup and egetent that all supports ${ROOT} option via --prefix in shadow utilities.
For now I've only added this option for linux.

However, I've encountered some unexpected issues: some ebuilds are using direct calls to chown and fowners. Both are not compatible with ${ROOT}...

To solve this, I've created 2 new calls in user.eclass: echown and efowners.
The only thing the new functions are doing is to get the uid/gid from the correct passwd/group files from ${ROOT} using the modified egetent function and pass that to the native chown/fowners...

For example, in sys-power/nut we can find:
chown nut:nut ${ROOT}/var/lib/nut

This should be changed to
echown nut:nut ${ROOT}/var/lib/nut

Same to fowners.
If the modification is not done, either the ebuild will fail because the nut user does not exists in the host, or the incorrect uid will be user in ${ROOT}

The solution is not perfect, but at least better than what we have today, and totally usable I believe.

I've uploaded the patches for lighttpd and nut, plus my patch for user.eclass for review in this bug... we do have time until upstream shadow team reviews and commits my modifications (at least).

Side note: it's a bit complicated to know when to add ${ROOT} and when not in a ebuild... For example, chown needs ${ROOT} but fowners must not!...
Side note 2: maybe I should add a verification to check if useradd/groupadd supports my new --prefix solution, and fallback to original behavior if not?

Tests: I've compiled a full working system with my above solution, and it works. (cross compilation in a dedicated target root path)

Regards,
Farid

[gentoo-dev] Re: Modification proposal for user/group creation when ROOT!="/"

[Benda Xu]

Hi Farid,

This is an excellent idea!  It is very helpful for Gentoo Prefix/libc,
where we maintain a set of nss databases (passwd, group, shadow, etc.)
inside a directory prefix.

Farid BENAMROUCHE <fariouche@yahoo.fr> writes:

> Currently there is an old known limitation when using ROOT= option to
> install a package in a folder: user/groups are created in the host
> filesystem, not the target root filesystem.

Exactly.

> So I've pushed some modifications to the upstream shadow repo.
> Basically, I've added a --prefix option to user{add,mod,del} and
> group{add,mod,del} This option does the same as --root option, but
> whithout a chroot (so compatible when cross compiling) 

Cool.

> You can see more details (and the limitation of my implementation) in
> the shadow github repo:
> https://github.com/shadow-maint/shadow/issues/18

Hope the upstream accept your patch soon.

> Now, for the gentoo part, I do have a working solution that I've
> pushed in the following bugzilla:
> https://bugs.gentoo.org/show_bug.cgi?id=541406
>
> A new user.eclass file with modified enewuser,enewgroup and egetent
> that all supports ${ROOT} option via --prefix in shadow utilities.
> For now I've only added this option for linux.

The new user.eclass requires the new shadow.  After the upstream makes a
new release, it will take a long time for Gentoo to use the feature.
Because we should carefully handle the compatibility with the old
systems.

> However, I've encountered some unexpected issues: some ebuilds are
> using direct calls to chown and fowners. Both are not compatible with
> ${ROOT}...

Those ebuilds are broken and should be fixed.

> To solve this, I've created 2 new calls in user.eclass: echown and
> efowners.  The only thing the new functions are doing is to get the
> uid/gid from the correct passwd/group files from ${ROOT} using the
> modified egetent function and pass that to the native chown/fowners...
>
> For example, in sys-power/nut we can find: chown nut:nut
> ${ROOT}/var/lib/nut
>
> This should be changed to echown nut:nut ${ROOT}/var/lib/nut

Brilliant.

> Same to fowners.  If the modification is not done, either the ebuild
> will fail because the nut user does not exists in the host, or the
> incorrect uid will be user in ${ROOT}
>
> The solution is not perfect, but at least better than what we have
> today, and totally usable I believe.
>
> I've uploaded the patches for lighttpd and nut, plus my patch for
> user.eclass for review in this bug... we do have time until upstream
> shadow team reviews and commits my modifications (at least).
>
> Side note: it's a bit complicated to know when to add ${ROOT} and when
> not in a ebuild... For example, chown needs ${ROOT} but fowners must
> not!...  

Why not?  Could you give more details?

> Side note 2: maybe I should add a verification to check if
> useradd/groupadd supports my new --prefix solution, and fallback to
> original behavior if not?

IMHO, useradd/groupadd supporting --prefix will be captured by a new
EAPI in the (far) future.  At present we don't need to worry about it.

> Tests: I've compiled a full working system with my above solution, and
> it works. (cross compilation in a dedicated target root path)

Do you have an overlay for me reproduce your result?  I am also
interested in hosting it in proj/android.git[1] if you do not have one
yet.

Keep on your good work.

Yours,
Benda   

1. https://gitweb.gentoo.org/proj/android.git/