Gentoo Archives: gentoo-dev

From: Benda Xu <heroxbd@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Modification proposal for user/group creation when ROOT!="/"
Date: Wed, 08 Jun 2016 05:45:19
Message-Id: 87fusoz12d.fsf_-_@gentoo.org
In Reply to: [gentoo-dev] Modification proposal for user/group creation when ROOT!="/" by Farid BENAMROUCHE
1 Hi Farid,
2
3 This is an excellent idea! It is very helpful for Gentoo Prefix/libc,
4 where we maintain a set of nss databases (passwd, group, shadow, etc.)
5 inside a directory prefix.
6
7 Farid BENAMROUCHE <fariouche@×××××.fr> writes:
8
9 > Currently there is an old known limitation when using ROOT= option to
10 > install a package in a folder: user/groups are created in the host
11 > filesystem, not the target root filesystem.
12
13 Exactly.
14
15 > So I've pushed some modifications to the upstream shadow repo.
16 > Basically, I've added a --prefix option to user{add,mod,del} and
17 > group{add,mod,del} This option does the same as --root option, but
18 > whithout a chroot (so compatible when cross compiling)
19
20 Cool.
21
22 > You can see more details (and the limitation of my implementation) in
23 > the shadow github repo:
24 > https://github.com/shadow-maint/shadow/issues/18
25
26 Hope the upstream accept your patch soon.
27
28 > Now, for the gentoo part, I do have a working solution that I've
29 > pushed in the following bugzilla:
30 > https://bugs.gentoo.org/show_bug.cgi?id=541406
31 >
32 > A new user.eclass file with modified enewuser,enewgroup and egetent
33 > that all supports ${ROOT} option via --prefix in shadow utilities.
34 > For now I've only added this option for linux.
35
36 The new user.eclass requires the new shadow. After the upstream makes a
37 new release, it will take a long time for Gentoo to use the feature.
38 Because we should carefully handle the compatibility with the old
39 systems.
40
41 > However, I've encountered some unexpected issues: some ebuilds are
42 > using direct calls to chown and fowners. Both are not compatible with
43 > ${ROOT}...
44
45 Those ebuilds are broken and should be fixed.
46
47 > To solve this, I've created 2 new calls in user.eclass: echown and
48 > efowners. The only thing the new functions are doing is to get the
49 > uid/gid from the correct passwd/group files from ${ROOT} using the
50 > modified egetent function and pass that to the native chown/fowners...
51 >
52 > For example, in sys-power/nut we can find: chown nut:nut
53 > ${ROOT}/var/lib/nut
54 >
55 > This should be changed to echown nut:nut ${ROOT}/var/lib/nut
56
57 Brilliant.
58
59 > Same to fowners. If the modification is not done, either the ebuild
60 > will fail because the nut user does not exists in the host, or the
61 > incorrect uid will be user in ${ROOT}
62 >
63 > The solution is not perfect, but at least better than what we have
64 > today, and totally usable I believe.
65 >
66 > I've uploaded the patches for lighttpd and nut, plus my patch for
67 > user.eclass for review in this bug... we do have time until upstream
68 > shadow team reviews and commits my modifications (at least).
69 >
70 > Side note: it's a bit complicated to know when to add ${ROOT} and when
71 > not in a ebuild... For example, chown needs ${ROOT} but fowners must
72 > not!...
73
74 Why not? Could you give more details?
75
76 > Side note 2: maybe I should add a verification to check if
77 > useradd/groupadd supports my new --prefix solution, and fallback to
78 > original behavior if not?
79
80 IMHO, useradd/groupadd supporting --prefix will be captured by a new
81 EAPI in the (far) future. At present we don't need to worry about it.
82
83 > Tests: I've compiled a full working system with my above solution, and
84 > it works. (cross compilation in a dedicated target root path)
85
86 Do you have an overlay for me reproduce your result? I am also
87 interested in hosting it in proj/android.git[1] if you do not have one
88 yet.
89
90 Keep on your good work.
91
92 Yours,
93 Benda
94
95 1. https://gitweb.gentoo.org/proj/android.git/