From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id BC85D1382C5 for ; Fri, 30 Mar 2018 18:52:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 55CB0E0973; Fri, 30 Mar 2018 18:52:23 +0000 (UTC) Received: from sonic301-22.consmr.mail.ir2.yahoo.com (sonic301-22.consmr.mail.ir2.yahoo.com [77.238.176.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D8601E095C for ; Fri, 30 Mar 2018 18:52:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; t=1522435940; bh=3iwEm0WX6T4wvcin/qFemc8vtjpkraKwhd7d19lOwwI=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=b2AyAx+jtFXLNupF10YOYWl3ugorcr5HvO3m0nMq3i6o1jc5Znt8E72VQkqSwEvTf/IHeu6nas7llLA3ewcK2nMTd2b5n5ueXFW7Nb93SuLQ6Lbm/IC7idYGt8RIH1d3L1mRMelSWs5ECcOMFLNl6AukTvkLnPlZxtU/Hu0Vyx8f4b9V5SPiHTNqXJcN/hqAA1z6BTAz7YwZ2A9qqN8QAVP2j3+zbnNL6LC5wJM/Mdv+Run+URMs2mvF4yiFcmSoN80QYAO8IpVM6qdEDAosQUj2SR0zQeLl9glTj6eNu612mbt+rY3o2OUPvQbmRbFbZMOFQ+sNyjPBaysToCVsVQ== X-YMail-OSG: rQVIDFkVM1nk.GP1WVCeMyy09duU4V5pHCAAr1j2zB2innOSSXbzbcmukEQlWrh cTbw872xyhZ94xKkj4Ca_qMhmf8FpaabrDZpQcFPP4efXhSn757iwiLZneZOgbDbx_JOK5IBRa2B c.qpXL6P2A5bR_JGgul8uvdlJ_.l9dt3Kdz6ts_3GCXy5gYBJAOrVdnoRCr8MAmQAXDgWEOnXU.V cpJOqFf.7A_rjN8TwKUdddHiM2CY76w6LCsIYPR0p46bqGSsc8w0OaifDpyyhdaMk78YbriX7bbZ czwpJrV8t2Pv7h1BlynZxi8Y6WRPhOiT5sdrN5tfRbe6.JfnE3aaPCw1Bl1m9O.FkmEz0J6WOz.X PVLl_l3uEY38_Xn2ncPEsgYvjkLFNBy6lYXy1lA1OSlkZKwonIn0KvZdNglOhEcq32WInD6dPA4W u_6LI8Hb.KTbGDspc7F4RL3CUECdr8zz.CVR6Kvx09JLk7ami0.W.g49Qb_0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ir2.yahoo.com with HTTP; Fri, 30 Mar 2018 18:52:20 +0000 Date: Fri, 30 Mar 2018 18:52:18 +0000 (UTC) From: Farid BENAMROUCHE To: , Farid BENAMROUCHE Message-ID: <160839029.2375229.1522435938193@mail.yahoo.com> Subject: [gentoo-dev] Re : Modification proposal for user/group creation when ROOT!="/" 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; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <160839029.2375229.1522435938193.ref@mail.yahoo.com> X-Mailer: WebService/1.1.11643 YahooMailBasic Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 X-Archives-Salt: d42c009e-affb-45ce-a1d6-7704681b2560 X-Archives-Hash: 858e5283873077c9d8123e165a66d7aa Hi all, Already two years.... Yes, two years ago I've posted here to notify you about the creattion of us= ers and groups when using "ROOT=3D". As a reminder, if you currently emerge a package to a specific rootfs folde= r, some packages will actually not create the user and groups correctly ins= ide this rootfs. It will also not check for the existance of the user/group inside of the ro= otfs. Everytime, it will check "/". This very old gentoo issue (I have to find again the GLEP talking about thi= s issue). The solution is not possible without changing the behaviour of the tools us= ed by portage. For example, portage is using shadow in most systems (and sh= adow is using the glibc). I've submited a patch first to shadow upstream team to avec this feature, u= sing 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 c= haonw directly. So I've added some wrappers (same as the current enewuser e= tc functions) This enable people to build embedded systems rootfs from scratch, using a c= omplete gentoo. Some packages must be updated in order to behave properly in that case (rep= lace 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 implement= ed (incorrect shadow version for example) This requires in that case a new EAPI I think. Just tell me what to do, whe= re, and I will submit the proposal I'm using the modifications for 2 years now. Limitations:=20 - selinux is not supported (ie: you will still use the system's selinux.).= =20 - Also, this only works with gentoo systems using the shadow package (the e= xact version will depend on when the new release will be done). - Last one: I only tested on a linux configuration Cheers -------------------------------------------- En date de=C2=A0: Mar 24.5.16, Farid BENAMROUCHE a =C3= =A9crit=C2=A0: Objet: Modification proposal for user/group creation when ROOT!=3D"/" =C3=80: gentoo-dev@lists.gentoo.org Date: Mardi 24 mai 2016, 21h00 =20 Hi all, =20 Currently there is an old known limitation when using ROOT=3D option to install a package in a folder: user/groups are created in the host filesystem, not the target root filesystem. =20 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 =20 =20 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=3D541406 =20 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. =20 However, I've encountered some unexpected issues: some ebuilds are using direct calls to chown and fowners. Both are not compatible with ${ROOT}... =20 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... =20 For example, in sys-power/nut we can find: chown nut:nut ${ROOT}/var/lib/nut =20 This should be changed to echown nut:nut ${ROOT}/var/lib/nut =20 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} =20 The solution is not perfect, but at least better than what we have today, and totally usable I believe. =20 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). =20 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? =20 Tests: I've compiled a full working system with my above solution, and it works. (cross compilation in a dedicated target root path) =20 Regards, Farid =20