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

[Benda Xu <heroxbd@gentoo.org>]

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/