On Sun, Oct 18, 2026 at 11:10 AM Jan Koester <[email protected]> wrote:
>
> Make kuid_t and kgid_t (and vfsuid_t and vfsgid_t, which share their
> layout) tagged unions: a classic 32 bit id, an RFC 9562 UUID, or a
> Microsoft GUID. KID_LEGACY is 0, so zeroed memory still holds the root
> ids, and KUIDT_INIT()/KGIDT_INIT() keep building classic ids, so the
> bulk of the kernel needs no change. The member is renamed from val to
> legacy so the compiler finds code that peeks at it directly.
>
> Semantics of the new ids:
>
> - They are not in any uid_map or gid_map: they exist in the initial
> user namespace only. kuid_has_mapping() is false for them in every
> other namespace, so no capability in a child namespace gives
> privilege over them, and from_kuid() and friends give -1 (the
> overflow id when munged), exactly as for any other id without a
> mapping. Anything that can only store or report a 32 bit id thereby
> already treats them safely.
Why?
>
> - Idmapped mounts map classic ids; UUIDs and GUIDs pass through them
> unchanged, as long as the filesystem itself is in the initial user
> namespace.
Okay, so they pass through but don't work. Sounds unfortunate.
> +/* Like kuid_t and kgid_t: a classic id, a UUID or a GUID */
> typedef struct {
> - uid_t val;
> + u32 type;
> + union {
> + uid_t legacy;
Linux is Linux. small numerical uids are not "legacy".
> + uuid_t uuid;
> + guid_t guid;
I'm at a complete loss. Is guid is only unique on Earth but uuid
unique in the entire universe? Even Microsoft admits that GUID and
UUID are two names for the same thing.
I realize that Microsoft colossally screwed up years ago with their
little endian uuid idea, and I sincerely hope that this is not some
endian thing.
