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 B8BA2139085 for ; Fri, 27 Jan 2017 21:15:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 97248E0E54; Fri, 27 Jan 2017 21:15:41 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 386C8E0E4E for ; Fri, 27 Jan 2017 21:15:41 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 69A493413B7; Fri, 27 Jan 2017 21:15:39 +0000 (UTC) Date: Fri, 27 Jan 2017 22:15:11 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: Michael Orlitzky Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Requirements for UID/GID management Message-ID: <20170127221511.55a559da.mgorny@gentoo.org> In-Reply-To: <9558d41c-17c0-4bbd-e2f8-02575c6d0ecd@gentoo.org> References: <9558d41c-17c0-4bbd-e2f8-02575c6d0ecd@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=pgp-sha512; boundary="Sig_/Kct_teJ3/v71iejDrwFaL7m"; protocol="application/pgp-signature" X-Archives-Salt: f54dafc6-6329-42f8-be1f-33308b933a4d X-Archives-Hash: afffcb7dde7bbac33441672847ca7130 --Sig_/Kct_teJ3/v71iejDrwFaL7m Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 27 Jan 2017 12:54:07 -0500 Michael Orlitzky wrote: > We approved GLEP 27 (https://wiki.gentoo.org/wiki/GLEP:27) in 2004 but > never implemented it. I'm wondering what are the explicit requirements > that we have for user and group management? I don't think GLEP 27 could be really considered approved if it hasn't seen any action for 12 years. > What I'm really wondering is, instead of the proposal in GLEP27, if we > couldn't simply handle users like any other package. For example, > net-dns/djbdns needs, >=20 > pkg_preinst() { > # The nofiles group is no longer provided by baselayout. > # Share it with qmail if possible. > enewgroup nofiles 200 >=20 > enewuser dnscache -1 -1 -1 nofiles > enewuser dnslog -1 -1 -1 nofiles > enewuser tinydns -1 -1 -1 nofiles > } >=20 > Instead of that, why couldn't we have something like, >=20 > (R)DEPEND=3D"sys-user/dnscache > sys-user/dnslog > sys-user/tinydns" >=20 > and then in each of those packages, >=20 > (R)DEPEND=3D"sys-group/nofiles" At a first glance it seems like a lot of effort for a problem that's already well-solved on the eclass level. However, it probably makes sense when you consider users/groups created by multiple packages. > That satisfies most of the requirements that *I* have for user and group > management on the system. Compared to the GLEP: >=20 > * EUSERS + EGROUPS: replaced by (R)DEPEND. > * Defining Accounts: anyone can add a new package already. > * FEATURES=3Dnoautoaccts: use package.provided instead. > * Local Overrides: use an overlay. > * users-update: cleanup can be done with --depclean now. Err, cleanup is never easy. You shouldn't really remove a user if it owns any files. I guess you could abuse pkg_prerm() for that but depclean will be terribly slow then. > You don't really have to care what UID/GID is assigned, because each > user/group will only be created once and referenced by name (as $PN). By > default, we could pick the first available UID in most packages. > I haven't thought much about the src_install implementation, but it > couldn't be *that* hard. Maybe install a $uid file to /var/lib/portage > somewhere to catch UID conflicts, and keep doing what user.eclass is > doing otherwise. Let's invent /etc/passwd.d and /etc/group.d ;-P. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/Kct_teJ3/v71iejDrwFaL7m Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEbbsHzE8NrQbqCv5BsHoa6u+0Rk4FAliLuGBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUACgkQsHoa6u+0 Rk6q2BAAzsVSIxhaUgMsFMe/7u3GP3hFn2Aw1ODFHJz16fvrt5+M94qqZ8/HHyX9 I8NLUlVPDOI4KJQTRA/TjoFW7zyQwSQyBIS97XbJip2ujmI02Qu2Ja+Aty/jIJEj Guf0XjdFeafcHR357xW91xIYgCKoEfq2yDouHsw+gTk0bbWC8iEM5or75mu8w2SR IoUgDRKJ6qSQc+hwulwRWLghzlewoY9vYwCh96knuLyEQwHSysojuhpU2A6NB8Qo oh+Jyn+dqShNQiD5Gb9I8ArTv9tM51MUV/NWcJLswwoko/uUNaZ1brG+WjPnJb39 5OHHXRg6cauVvbFHgyJOK9F/kgs6W3oZozmlnSEsKKDwcSWEiu5bww3t2J37duNn Jg3WzIcEKXROBjrkchwhZEG3tr1h7z6SWj/cCxa8sp4lVnp4ARg/pcUo0ElWTZ3I GYnAy7GgDefB71PCXuTL2f+DZGmZrV0yNJQkr1bz88Fh+MQmO2S7gypjdcdQybKj 57rwc1kn9w2QOP9ujY7s2Rn3kYNg6iVJrS82maAr6IntPUI6RiVCCXJAzHWVCimx SJyZMVDetDB4753Kq/NybElFVcFa7jfvv3wNlRWf8eTDxWokLwD6ePjJ/SSzp4HL 5KELS/Ibrraza64ESlj9ErI4iILOVYi0gWHdWQZHMJpKH3ztNvg= =l/nw -----END PGP SIGNATURE----- --Sig_/Kct_teJ3/v71iejDrwFaL7m--