| 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 |
Archives