From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-79357-garchives=archives.gentoo.org@lists.gentoo.org>
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 <garchives@archives.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; 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 <chutzpah@gentoo.org>
To: Rich Freeman <rich0@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Requirements for UID/GID management
Message-ID: <20170127183752.500f8910@patrickm>
In-Reply-To: <CAGfcS_=V+xmBU+fFbMQBH39E9-y9CUaZt9Bok80Wg6_jboHcbQ@mail.gmail.com>
References: <9558d41c-17c0-4bbd-e2f8-02575c6d0ecd@gentoo.org>
	<CAGfcS_=biacBM0xsy0GX3_X0mOAd3BdgHDXYorSBkmwsoQ9sgQ@mail.gmail.com>
	<ee24eb83-4430-40ff-07d0-577bc188457d@gentoo.org>
	<CAGfcS_=V+xmBU+fFbMQBH39E9-y9CUaZt9Bok80Wg6_jboHcbQ@mail.gmail.com>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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 <rich0@gentoo.org> wrote:

> On Fri, Jan 27, 2017 at 2:35 PM, Michael Orlitzky <mjo@gentoo.org>
> 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.