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 <fariou...@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/
