From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 5C8E513829C for ; Wed, 8 Jun 2016 05:45:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 080AE1426A; Wed, 8 Jun 2016 05:45:11 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id ECAF921C012 for ; Wed, 8 Jun 2016 05:45:09 +0000 (UTC) Received: from proton (unknown [133.11.177.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: heroxbd) by smtp.gentoo.org (Postfix) with ESMTPSA id 4DDE1340B25 for ; Wed, 8 Jun 2016 05:45:08 +0000 (UTC) From: Benda Xu To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: Modification proposal for user/group creation when ROOT!="/" References: <1187243158.3442649.1464116425074.JavaMail.yahoo.ref@mail.yahoo.com> <1187243158.3442649.1464116425074.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 08 Jun 2016 14:44:58 +0900 In-Reply-To: <1187243158.3442649.1464116425074.JavaMail.yahoo@mail.yahoo.com> (Farid BENAMROUCHE's message of "Tue, 24 May 2016 19:00:25 +0000 (UTC)") Message-ID: <87fusoz12d.fsf_-_@gentoo.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain X-Archives-Salt: baeb7319-10a4-4ac6-93ed-2d91c6eba117 X-Archives-Hash: ea8dc890c0e94a869e2c48b832730e4f 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 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/