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

[Farid BENAMROUCHE]

Hi,

I only have a local overlay for now.
The shadow team still did'nt had time to merge my pull request on github.
But you can use my github branch:
https://github.com/fariouche/shadow.git

In the bugzilla you will find all the needed patches, except the shadow ebuild modified to use my branch.
Feel free to host the overlay if you want to test. It's pretty straightforward. :-)


I feel like an ebuild should never use directly the $ROOT prefix. I believe it is prone to errors and is better suited to be handled by the portage installation system.

Regards,
Farid

--------------------------------------------
En date de : Mer 8.6.16, Benda Xu <heroxbd@g.o> a écrit :

 Objet: [gentoo-dev] Re: Modification proposal for user/group creation when ROOT!="/"
 À: gentoo-dev@l.g.o
 Date: Mercredi 8 juin 2016, 6h44
 
 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@×××××.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/