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 E6427139085 for ; Fri, 27 Jan 2017 17:54:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2412523400F; Fri, 27 Jan 2017 17:54:11 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.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 CA6BA21C04E for ; Fri, 27 Jan 2017 17:54:10 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id A813D3414E9 for ; Fri, 27 Jan 2017 17:54:09 +0000 (UTC) To: gentoo-dev@lists.gentoo.org From: Michael Orlitzky Subject: [gentoo-dev] Requirements for UID/GID management Message-ID: <9558d41c-17c0-4bbd-e2f8-02575c6d0ecd@gentoo.org> Date: Fri, 27 Jan 2017 12:54:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 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: 7bit X-Archives-Salt: dfee1d31-1809-414e-a565-26d4bfae09d7 X-Archives-Hash: 2355afd4f5b72651e2ff47ea8b10c1fe 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? 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, pkg_preinst() { # The nofiles group is no longer provided by baselayout. # Share it with qmail if possible. enewgroup nofiles 200 enewuser dnscache -1 -1 -1 nofiles enewuser dnslog -1 -1 -1 nofiles enewuser tinydns -1 -1 -1 nofiles } Instead of that, why couldn't we have something like, (R)DEPEND="sys-user/dnscache sys-user/dnslog sys-user/tinydns" and then in each of those packages, (R)DEPEND="sys-group/nofiles" That satisfies most of the requirements that *I* have for user and group management on the system. Compared to the GLEP: * EUSERS + EGROUPS: replaced by (R)DEPEND. * Defining Accounts: anyone can add a new package already. * FEATURES=noautoaccts: use package.provided instead. * Local Overrides: use an overlay. * users-update: cleanup can be done with --depclean now. 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. There isn't a ton of motivation in that GLEP, so I'm not sure what other use cases I might have overlooked.