| 1 |
On 12/10/19 11:05 AM, Joonas Niilola wrote: |
| 2 |
> |
| 3 |
> I was more thinking along sys admins being able to modify their acct- |
| 4 |
> ebuilds with static numbers. If you're bind-mounting already, why not |
| 5 |
> bind your portage (or local overlay) to children as well. 2 minute more |
| 6 |
> work for those who need it, but a lot easier to everyone else who don't |
| 7 |
> care :) |
| 8 |
> |
| 9 |
|
| 10 |
For most people, it's more convenient if the users/groups have the same |
| 11 |
IDs on every system, but they don't actually care what those IDs are. |
| 12 |
That's why it is the way it is, where developers pick basically any ID, |
| 13 |
write it down, and hard-code it in the ebuild. |
| 14 |
|
| 15 |
(Cross-distro compatibility is a stretch, but if we can make it work |
| 16 |
easily in some cases then I don't see any harm in trying.) |
| 17 |
|
| 18 |
If you need a specific ID, then by design you can make a new revision of |
| 19 |
the ebuild in an overlay and tell the eclass to enforce your special ID. |
| 20 |
But what we don't want is to force *every* user to create his own |
| 21 |
overlay with *every* acct- ebuild just to get the same IDs on two |
| 22 |
machines, since that's the sensible thing to do in the first place. |
| 23 |
|
| 24 |
In any case, the collisions aren't why I supported mailing list review. |
| 25 |
Users and groups are the most fundamental concept in UNIX security, and |
| 26 |
the review requirement just reflects my belief that we can take a day or |
| 27 |
two to make sure that we get them right. |
Archives