4 ms·
> The user is automatically allocated from the UID range 61184–65519, by looking for a so far unused UID. WAT. That's not OK. The UID (and GID) namespace is
by cryptonector 8y ago
> The user is automatically allocated from the UID range 61184–65519, by looking for a so far unused UID.
WAT. That's not OK. The UID (and GID) namespace is not that big (32-bit), but it's big enough to avoid conflicts with existing uses: just use a range within the larger range between (uid_t)(1UL<<31) and (uid_t)(-2).
Solaris 11+ and Illumos do this for dynamically assigning UIDs and GIDs to SIDs that are not mapped by name to Unix users/groups.
- JdeBP 8y agoSystemd already reduces UIDs to 16 bits, using the upper 16 bits for container IDs. * https://news.ycombinator.com/item?id=10519578 https://news.ycombinator.com/item?id=10519578
- cryptonector 8y agoThat's dumb. There should be a container ID.
- LukeShu 8y agoInside of a container (with user namespacing enabled), you won't have the full 32-bit range, and this must all work inside of containers; I'm not sure about other container managers off the top of my head, but systemd-npawn only gives containers a 16-bit subrange.
- cryptonector 8y agoThe container UID namespaces should be the same size, damnit. (That is how it is in Solaris/Illumos zones...)
- LukeShu 8y agoLinux user namespaces work as a 1-to-1 mapping of UIDs. Every UID in the container has to map to a UID on the host, so the UID range of the container is necessarily smaller than the UID range of the host (unless of course the map is the identity, but then what's the point of having a separate namespace?). Maybe that is bad design, but if it is: it's Linux's fault, not systemd's.