On Fri, 27 Jan 2017 14:53:18 -0500 Rich Freeman <[email protected]> wrote:
> On Fri, Jan 27, 2017 at 2:35 PM, Michael Orlitzky <[email protected]> > 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.
