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.
next prev 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