1 |
>>>>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote: |
2 |
|
3 |
> Make complete SYS_UID_MIN - SYS_UID_MAX range available for GLEP 81. |
4 |
|
5 |
> The only argument/reason I am aware of, "but 501-999 could be used by |
6 |
> system" (Dynamic allocation by user.eclass), isn't strong enough from my |
7 |
> POV because system administrator can already pick something between |
8 |
> SYS_UID_MIN-MAX so system must be already capable of dealing with such |
9 |
> scenarios. So why do you think this range must be reserved? Isn't |
10 |
> blocking 501-999 just another random choice? |
11 |
|
12 |
> Therefor I would change the recommendation to pick highest free number. |
13 |
> I.e. it should be recommended to pick the lowest free UID/GID pair |
14 |
> instead (just to avoid fragmentation and keep 501+ free as long as |
15 |
> possible). |
16 |
|
17 |
One problem with that is that at some time user.eclass dynamically |
18 |
allocated IDs starting at 101 upwards, and later this was changed to 999 |
19 |
downwards (at different times for UIDs and GIDs). So for existing |
20 |
systems you can expect some range above 101 and some range below 999 to |
21 |
be occupied. So it may not be the best idea to start picking IDs from |
22 |
101 upwards, which are most likely to collide. |
23 |
|
24 |
If the range below 500 should fill up completely, we can always |
25 |
reconsider. |
26 |
|
27 |
Ulrich |