> On disk, the only real issue is chown(2) and friends. They can return
> -EINVAL if they can't change the UID to that value. This appears to be
> what Solaris does (although I'm not sure what filesystems it would affect...
> the man page for chown(2) mentioned "EINVAL group or owner is out of range".
>> __u16 had been used in
>> APIs, which makes the transition to 32bit uids a little painful.
>
> Quite.
Besides trunctuation (aliasing), we get sign extension.
After some 16-bit abuse, 0x0001ffff can become 0xffffffff
(UID -1 is special) and 0x12340000 can become 0.
>> - what happens when you use a system call with a 16bit uid when your
>> uid is >=65535.
>
> Probably -EPERM or -EINVAL.
What about when an old server with 16-bit UIDs checks for root?
This isn't just a kernel problem. I could imagine sudo giving out
access to users 0x00001234, 0x10001234, and 0x0a001234.
I know! We could use the RSBAC patches to enforce MAC between old
executables and new users. That's about what it would take.
>> It doesn't look like that much work to implement, but it's definately
>> a 2.3 project.
Not for the Alpha.
> Absolutely. Early in 2.3 we should expand almost all the types
> (uid_t, gid_t, pid_t, off_t, ...).
It is generally bad to go past 99999, since all sorts of reporting tools
get hopelessly messed up. It is _not_ an issue of "fix the tools" though,
since there simply isn't enough room on a standard 80-column display.
Imagine something like /bin/ps with lines wrapped... eww, unreadable mess!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/