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 B0B4B139085 for ; Sat, 28 Jan 2017 02:38:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D4711E0D3D; Sat, 28 Jan 2017 02:37:56 +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 8ADD0E0D33 for ; Sat, 28 Jan 2017 02:37:56 +0000 (UTC) Received: from patrickm (unknown [100.42.98.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: chutzpah) by smtp.gentoo.org (Postfix) with ESMTPSA id 2B2F234166E; Sat, 28 Jan 2017 02:37:54 +0000 (UTC) Date: Fri, 27 Jan 2017 18:37:52 -0800 From: Patrick McLean To: Rich Freeman Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Requirements for UID/GID management Message-ID: <20170127183752.500f8910@patrickm> In-Reply-To: References: <9558d41c-17c0-4bbd-e2f8-02575c6d0ecd@gentoo.org> 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 65aa7492-27bd-4f0c-bf23-d0b76fd6ca73 X-Archives-Hash: 099c288db606d3c9121ba9ea589eb721 On Fri, 27 Jan 2017 14:53:18 -0500 Rich Freeman wrote: > On Fri, Jan 27, 2017 at 2:35 PM, Michael Orlitzky > wrote: > > On 01/27/2017 01:52 PM, Rich Freeman wrote: > >> > >> This doesn't really seem like a problem though. Just have a table > >> somewhere (wiki?) to track who is using what UID/GID and encode > >> those defaults into the ebuild that creates those users. > >> > > > > It should be possible to have two different users with the same UID > > in the tree, just like we can have two different packages that > > install the same file. Eventually somebody will notice a file > > collision, and then we add a blocker per usual. > > > > I'm not saying we can't have random assignment for things where it > doesn't matter, or fall back to random assignment, but it seems rather > silly to go to all the trouble to have blockers when it would be just > as easy to not have a conflict in the first place. Now, if we have > some longstanding issue from the past that might be another matter, > but what's wrong with just picking an unused ID (again, for stuff that > needs it)? > > Telling users that they can't have postfix and apache on the same box > because nobody can be bothered to pick IDs that don't collide seems > like an arbitrary imposition. Sometimes upstream creates conflicts > that are just hard to work around (same SONAME, different ABI or even > API, and so on). And if we were talking about some binary-only > upstream package that relies on hardcoded UIDs I guess blockers might > be our only option, and users will just have to be happy that we're > able to support it at all. However, we shouldn't be the ones creating > these kinds of conflicts. > I don't think we need to have stable UIDs/GIDs in the "normal" case of standalone users with a single Gentoo system at home. The people who need predictable UIDs/GIDs are the "enterprise" users or the home users who use things such as NFS. I work for a company that uses Gentoo, we have a bunch of workarounds to make sure that UIDs and GIDs are stable. To make something to solve our problem (and I suspect everyone else who cares about this), it would be sufficient to have a mechanism to override the default random assignment with a fixed UID/GID. Possibly some file in /etc/portage or in the profile (or both) that allows one to configure what UID/GID a user will get when the user is being created. One advantage of this is that user.eclass could be modified to support it, so we don't have to wait for a new EAPI before taking advantage of it.