1 |
>>>>> On Thu, 11 Nov 2021, Jaco Kroon wrote: |
2 |
|
3 |
> # getent passwd | awk -F: '{ print $3 }' | sort -g | tail -n3 |
4 |
> 37945 |
5 |
> 37946 |
6 |
> 65534 <-- this happens to be nobody. |
7 |
|
8 |
> 60000 up to where? 65533? |
9 |
|
10 |
I'd say 60001..60999 for now, and increase by another 1000 when (and if) |
11 |
it will become necessary. |
12 |
|
13 |
> I'll need to make a "hole" in our |
14 |
> allocations but that's perfectly do-able. Others may run into similar |
15 |
> issues and be caught unawares (especially if UID/GID values are |
16 |
> allocated from some other system which may not be aware of UID/GID |
17 |
> values on specific servers). Might be worth the trouble to head to |
18 |
> >=2^31, but that will again fail on systems that still use 16-bit |
19 |
> UID/GID values (I'm not aware that we still support kernels older than 2.4). |
20 |
|
21 |
More than 16 bits may be problematic with containers. IIUC some of them |
22 |
use a split scheme where the upper 16 bits are reserved. |
23 |
|
24 |
> https://systemd.io/UIDS-GIDS/ basically says system users (which we're |
25 |
> discussing here) is <1000. systemd also already violates this statement |
26 |
> itself just a few paragraphs down with special systemd UID and GID |
27 |
> ranges. And already >60000 ranges listed here (most of 60000 to 65533 |
28 |
> is reserved by systemd). |
29 |
|
30 |
That's not a standard in any case, and it's dynamic allocation. So as |
31 |
long as we don't fill up the whole range, things should be fine. |
32 |
|
33 |
Ulrich |