Hi Ludovic,
Ludovic Courtès <l...@gnu.org> writes:
> IDs as hash of the user names are interesting because that’d be
> stateless (conversely, the current ID allocation strategy is stateful:
> it arranges to not reuse recently-freed IDs.)
>
> But like you write, we’d need 32-bit UIDs. In libc, ‘uid_t’
> (specifically ‘__UID_T_TYPE’ in typesizes.h) is 32-bit, so it might work
> rather well in user space.
The kernel and core system components certainly support 32-bit UIDs, and
have for around 20 years.
> It still sounds like a change with significant implications though, and
> it’s hard to predict exactly how it would go or what would break.
Right, my concern is with the vast majority of programs and libraries in
Guix, most of which probably haven't seen much (if any) testing with
large UIDs.
> For example, that does away with the system/non-system ranges, and
> wouldn’t play well with “special” IDs like 0 and 65535.
This particular issue is easily addressed. It's easy enough to find a
function from 31-hash values to 32-bit IDs that's injective and avoids
any chosen subset of special IDs, as long as there are fewer than 2^31
special IDs.
Simply adding 65536 (or even 2^31) to the hash value would be one easy
option.
What do you think?
Mark
