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

[Farid BENAMROUCHE]

Hi all,

Already two years....
Yes, two years ago I've posted here to notify you about the creattion of users and groups when using "ROOT=".
As a reminder, if you currently emerge a package to a specific rootfs folder, some packages will actually not create the user and groups correctly inside this rootfs.
It will also not check for the existance of the user/group inside of the rootfs.
Everytime, it will check "/".

This very old gentoo issue (I have to find again the GLEP talking about this issue).

The solution is not possible without changing the behaviour of the tools used by portage. For example, portage is using shadow in most systems (and shadow is using the glibc).

I've submited a patch first to shadow upstream team to avec this feature, using a new argument (--prefix) to tools like usemod,useradd etc
You can create users in any rootfs you want, no need to be root (except if you local pam configuration requires it)

This is unfortunately not enough for gentoo: some packages are relying on chaonw directly. So I've added some wrappers (same as the current enewuser etc functions)
This enable people to build embedded systems rootfs from scratch, using a complete gentoo.
Some packages must be updated in order to behave properly in that case (replace chown with echown for example)
As a failsafe, I'm only triggering the new behavior in case ROOT env var is not "/" (and I think (I have to check) that if the command fails, it will fallback to the old behavior in case the --prefix argument is not implemented (incorrect shadow version for example)

This requires in that case a new EAPI I think. Just tell me what to do, where, and I will submit the proposal

I'm using the modifications for 2 years now.


Limitations: 
- selinux is not supported (ie: you will still use the system's selinux.). 
- Also, this only works with gentoo systems using the shadow package (the exact version will depend on when the new release will be done).
- Last one: I only tested on a linux configuration


Cheers


--------------------------------------------
En date de : Mar 24.5.16, Farid BENAMROUCHE <fariouche@×××××.fr> a écrit :

 Objet: Modification proposal for user/group creation when ROOT!="/"
 À: gentoo-dev@l.g.o
 Date: Mardi 24 mai 2016, 21h00
 
 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