| 1 |
On 01/29/2017 03:26 AM, Alan McKinnon wrote: |
| 2 |
>> |
| 3 |
>> Can anyone think of an upgrade path for fixed UIDs? That issue aside, I |
| 4 |
>> may have convinced myself that fixed UIDs are better. |
| 5 |
> |
| 6 |
> The general process I would recommend is that if the ebuild finds the user |
| 7 |
> already exists, leave it, it's UID and it's file ownerships alone, and keep |
| 8 |
> them as they are. If the user does not exist then create it. |
| 9 |
|
| 10 |
That's what I've got it doing now... |
| 11 |
|
| 12 |
|
| 13 |
> Preferably use a pre-assigned UID/GID so there is some consistency |
| 14 |
> with most other Gentoo things out there. |
| 15 |
|
| 16 |
This is the only point we have left to consider. To recap, there are |
| 17 |
three approaches to try: |
| 18 |
|
| 19 |
1 Truly fixed IDs. Every user gets the UID it wants, or it doesn't |
| 20 |
get created. The UIDs are all determined beforehand. |
| 21 |
|
| 22 |
Pros: |
| 23 |
|
| 24 |
* Cleaner code |
| 25 |
* UIDs agree on all systems |
| 26 |
* Sweet subslot rebuilds |
| 27 |
* Could decide on UIDs to match e.g. Debian |
| 28 |
|
| 29 |
Cons: |
| 30 |
|
| 31 |
* Absolutely no way to introduce it into the tree |
| 32 |
without breaking every existing system. |
| 33 |
|
| 34 |
|
| 35 |
2 Mostly random UIDs, and the few packages that need to specify one |
| 36 |
can do so. Usually installation will never fail, but if some user |
| 37 |
specifies a particular UID and doesn't get it, we die(). |
| 38 |
|
| 39 |
Pros (w.r.t. option 3): |
| 40 |
|
| 41 |
* The upgrade path is a little smoother. Most packages don't care |
| 42 |
about their UID, and the UIDs on your system *right now* are all |
| 43 |
random, so the upgrade path is "leave them there." |
| 44 |
|
| 45 |
Cons (w.r.t. option 3): |
| 46 |
|
| 47 |
* The UIDs on your system will never be predictable, and anyone |
| 48 |
who needs their UIDs consistent across systems will have to |
| 49 |
create an overlay that changes the behavior of a few ebuilds. |
| 50 |
|
| 51 |
3 Mostly fixed UIDs, but with a fallback to random ones if you don't |
| 52 |
get the UID you want. Here, everyone specifies their "preferred" |
| 53 |
UID, and we try that first. If it doesn't work, you get the random |
| 54 |
assignment. |
| 55 |
|
| 56 |
Pros (w.r.t option 2): |
| 57 |
|
| 58 |
* On a new installation, all of the UIDs that are assigned will |
| 59 |
likely be fixed, so you get some of the benefit of the first |
| 60 |
option without having to create an overlay. |
| 61 |
|
| 62 |
Cons (w.r.t. option 2): |
| 63 |
|
| 64 |
* The upgrade path is a little hairier. On an existing system, |
| 65 |
we'll be introducing a bunch of new user packages that want |
| 66 |
a particular UID but don't get it. On existing systems, the |
| 67 |
UID assignment will still essentially be random. That's |
| 68 |
problematic for packages that truly need the UID they've |
| 69 |
requested. |
| 70 |
|
| 71 |
Option #1 is pretty much dead in the water without an upgrade path. |
| 72 |
We're considering #2 and #3 at the moment, but they're really not |
| 73 |
that different. |
| 74 |
|
| 75 |
|
| 76 |
> It could output an elog |
| 77 |
> saying the uid/gid doesn't match the new Gentoo norm, and provide the |
| 78 |
> commands to run to bring things into line (usermod, groupmod, find / |
| 79 |
> -user -exec chown, etc, etc) |
| 80 |
> |
| 81 |
|
| 82 |
There's no safe way to do that. If you call chown (as root) on |
| 83 |
everything in a user-owned directory, that user can just create a |
| 84 |
symlink to e.g. /root/.bashrc and you'll give it root. It's really a |
| 85 |
miserable time trying to switch ownership of anything safely once it's |
| 86 |
been created. |
Archives