1 |
On Fri, 27 Jan 2017 14:53:18 -0500 |
2 |
Rich Freeman <rich0@g.o> wrote: |
3 |
|
4 |
> On Fri, Jan 27, 2017 at 2:35 PM, Michael Orlitzky <mjo@g.o> |
5 |
> wrote: |
6 |
> > On 01/27/2017 01:52 PM, Rich Freeman wrote: |
7 |
> >> |
8 |
> >> This doesn't really seem like a problem though. Just have a table |
9 |
> >> somewhere (wiki?) to track who is using what UID/GID and encode |
10 |
> >> those defaults into the ebuild that creates those users. |
11 |
> >> |
12 |
> > |
13 |
> > It should be possible to have two different users with the same UID |
14 |
> > in the tree, just like we can have two different packages that |
15 |
> > install the same file. Eventually somebody will notice a file |
16 |
> > collision, and then we add a blocker per usual. |
17 |
> > |
18 |
> |
19 |
> I'm not saying we can't have random assignment for things where it |
20 |
> doesn't matter, or fall back to random assignment, but it seems rather |
21 |
> silly to go to all the trouble to have blockers when it would be just |
22 |
> as easy to not have a conflict in the first place. Now, if we have |
23 |
> some longstanding issue from the past that might be another matter, |
24 |
> but what's wrong with just picking an unused ID (again, for stuff that |
25 |
> needs it)? |
26 |
> |
27 |
> Telling users that they can't have postfix and apache on the same box |
28 |
> because nobody can be bothered to pick IDs that don't collide seems |
29 |
> like an arbitrary imposition. Sometimes upstream creates conflicts |
30 |
> that are just hard to work around (same SONAME, different ABI or even |
31 |
> API, and so on). And if we were talking about some binary-only |
32 |
> upstream package that relies on hardcoded UIDs I guess blockers might |
33 |
> be our only option, and users will just have to be happy that we're |
34 |
> able to support it at all. However, we shouldn't be the ones creating |
35 |
> these kinds of conflicts. |
36 |
> |
37 |
|
38 |
I don't think we need to have stable UIDs/GIDs in the "normal" case of |
39 |
standalone users with a single Gentoo system at home. The people who |
40 |
need predictable UIDs/GIDs are the "enterprise" users or the home users |
41 |
who use things such as NFS. I work for a company that uses Gentoo, we |
42 |
have a bunch of workarounds to make sure that UIDs and GIDs are |
43 |
stable. To make something to solve our problem (and I suspect everyone |
44 |
else who cares about this), it would be sufficient to have a mechanism |
45 |
to override the default random assignment with a fixed UID/GID. |
46 |
Possibly some file in /etc/portage or in the profile (or both) that |
47 |
allows one to configure what UID/GID a user will get when the user is |
48 |
being created. One advantage of this is that user.eclass could be |
49 |
modified to support it, so we don't have to wait for a new EAPI before |
50 |
taking advantage of it. |