| 1 |
Hi, |
| 2 |
|
| 3 |
On 2021/11/11 14:10, Pacho Ramos wrote: |
| 4 |
> In any case, 300 additional IDs may not be future proof at the rate |
| 5 |
>> we're currently allocating them. So I wonder if we shouldn't move to |
| 6 |
>> above 60000 immediately, or alternatively, give up the whole concept. |
| 7 |
>> |
| 8 |
>> Ulrich |
| 9 |
> Personally I would move to >60000 and keep the 300 additional IDs for the case |
| 10 |
> some software really really needs them |
| 11 |
|
| 12 |
# getent passwd | awk -F: '{ print $3 }' | sort -g | tail -n3 |
| 13 |
37945 |
| 14 |
37946 |
| 15 |
65534 <-- this happens to be nobody. |
| 16 |
|
| 17 |
>60000 up to where? 65533? I'll need to make a "hole" in our |
| 18 |
allocations but that's perfectly do-able. Others may run into similar |
| 19 |
issues and be caught unawares (especially if UID/GID values are |
| 20 |
allocated from some other system which may not be aware of UID/GID |
| 21 |
values on specific servers). Might be worth the trouble to head to |
| 22 |
>=2^31, but that will again fail on systems that still use 16-bit |
| 23 |
UID/GID values (I'm not aware that we still support kernels older than 2.4). |
| 24 |
|
| 25 |
https://systemd.io/UIDS-GIDS/ basically says system users (which we're |
| 26 |
discussing here) is <1000. systemd also already violates this statement |
| 27 |
itself just a few paragraphs down with special systemd UID and GID |
| 28 |
ranges. And already >60000 ranges listed here (most of 60000 to 65533 |
| 29 |
is reserved by systemd). |
| 30 |
|
| 31 |
Kind Regards, |
| 32 |
Jaco |
Archives