public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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
Date: Fri, 27 Jan 2017 18:37:52 -0800	[thread overview]
Message-ID: <20170127183752.500f8910@patrickm> (raw)
In-Reply-To: <CAGfcS_=V+xmBU+fFbMQBH39E9-y9CUaZt9Bok80Wg6_jboHcbQ@mail.gmail.com>

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.


  parent reply	other threads:[~2017-01-28  2:38 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-27 17:54 [gentoo-dev] Requirements for UID/GID management Michael Orlitzky
2017-01-27 18:19 ` Alexis Ballier
2017-01-27 18:52 ` Rich Freeman
2017-01-27 19:35   ` Michael Orlitzky
2017-01-27 19:53     ` Rich Freeman
2017-01-27 20:09       ` Michael Orlitzky
2017-01-27 21:23         ` Rich Freeman
2017-01-28  3:02           ` [gentoo-dev] " Duncan
2017-01-28  2:37       ` Patrick McLean [this message]
2017-01-28  3:20         ` [gentoo-dev] " Michael Orlitzky
2017-01-28  4:21         ` Rich Freeman
2017-01-29  1:56           ` Michael Orlitzky
2017-01-29  2:22             ` Rich Freeman
2017-01-29  2:48               ` Michael Orlitzky
2017-01-29  2:54               ` Michael Orlitzky
2017-01-29  3:23                 ` Gordon Pettey
2017-01-29  3:36                   ` M. J. Everitt
2017-01-29  3:42                   ` Michael Orlitzky
2017-01-29 10:03                     ` Ulrich Mueller
2017-01-29 11:16                       ` Michał Górny
2017-01-29 17:19                       ` Michael Orlitzky
2017-01-29  3:05             ` M. J. Everitt
2017-01-29  8:26             ` Alan McKinnon
2017-01-29 17:05               ` Michael Orlitzky
2017-01-29 17:22                 ` A. Wilcox
2017-01-29 19:31                   ` james
2017-01-29 22:07                 ` Alan McKinnon
2017-01-29 22:20                   ` Michael Orlitzky
2017-01-29 22:30                     ` Alan McKinnon
2017-01-29 23:04                       ` Michael Orlitzky
2017-01-30 14:25                         ` Alan McKinnon
2017-01-30 16:29                           ` Michael Orlitzky
2017-01-30 18:05                             ` Patrick McLean
2017-01-30 18:22                               ` Michael Orlitzky
2017-01-30 18:43                                 ` Kristian Fiskerstrand
2017-02-03 14:51                                 ` [gentoo-dev] " Martin Vaeth
2017-02-03 19:29                                   ` Michael Orlitzky
2017-02-04  8:50                                     ` Christopher Head
2017-02-04 15:02                                       ` Michael Orlitzky
2017-02-04 18:03                                       ` Martin Vaeth
2017-01-28 11:28         ` [gentoo-dev] " James Le Cuirot
2017-01-28 22:54           ` Patrick McLean
2017-01-28 18:13         ` A. Wilcox
2017-01-28 19:32           ` James Le Cuirot
2017-01-28 20:34             ` Rich Freeman
2017-01-28 21:29               ` James Le Cuirot
2017-01-29 17:16             ` A. Wilcox
2017-01-29 17:34               ` James Le Cuirot
2017-01-27 19:45   ` Gregory Woodbury
2017-01-28 11:32   ` Tom H
2017-01-27 21:15 ` Michał Górny
2017-01-28  0:10   ` Michael Orlitzky
2017-01-29 22:13 ` Michael Orlitzky
2017-01-29 23:34   ` Ulrich Mueller
2017-01-29 23:45     ` Michael Orlitzky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170127183752.500f8910@patrickm \
    --to=chutzpah@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=rich0@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox