In my patch against Linux 2.2, I've tried to do everything in a 'nice'
way: both the new 32-bit UID system calls and the old 16-bit backwards
compatibility system calls are config options, so that you can compile a
kernel with one or both enabled. The system calls that need to return
16-bit uids/gids to old programs do so via a macro, high2lowuid(), that
returns a fixed value in lieu of uid mod 65536.
I'm interested in what people think of the approach in my patch, i.e. does
it fall under the category of:
o Perfect - it does everything the way you wanted.
o Some issues - i.e. my handling of IPC semctl(), msgctl(), and shmctl(),
ext2 changes should be removed and wait for later, etc.
o Completely 100% incorrect- I should go bury my patch in the litter box
How much backwards compatibility do you think there should be:
o Support all old binaries and make things as nice as possible, never
return 0 instead of 65536 (this is what my patch does)
o Support all old binaries, but don't worry about old binaries seeing
weird uids/gids; you shouldn't be running any old binaries as root
anyway
o No kernel support for old binaries; leave it up to libc to do this or
not. No sympathy for old statically linked programs.
o No backwards compatibility at all.
When do you think the right time is to add 32-bit UID support in Linux?
o As soon as I write a suitable patch for 2.3 that is to everyone's
liking
o Not until the same parts of the kernel that my patch touches need to
be changed for other reasons (i.e. for 64-bit file support on 32-bit
platforms)
o Never
(this would make me sad)
Some questions I have in particular are:
- supporting 32-bit UIDs in semctl(), shmctl(), and msgctl() is
more of a pain because glibc just passes an unadulterated structure
between kernel and user. Morever, the kernel structure doesn't leave room
to add extra bits, so I ended up duplicating most of the code in the
xxxctl() functions into 16-bit UID and 32-bit UID versions.
Is there a better way to do this, and more importantly, is there
another reason why the Linux SysV IPC subsystem should be overhauled
completely (the words 'POSIX IPC' stick in my mind here, although I don't
know exactly what that means)
- why is the system call table for sparc populated in a 'sparse'
manner? is this to locate things on the same cache line, etc?
In my personal opinion, I think any eventual 32-bit UID support in Linux
should do the following:
- All architectures should support 32-bit UIDs
- All system calls should support 32-bit UIDs (filesystem, process
control, and IPC)
- There should be at least one 'official' filesystem that supports 32-bit
UIDs
I realize that 32-bit UIDs are not a very big deal from a
technical standpoint. However, while the number of places that need 32-bit
UIDs may be small, they all typically have very large numbers of users.
Thus, lack of support for 32-bit UIDs in the future may result in the loss
of a significant number of users for Linux.
I realize also that filesystem changes are another issue
altogether, and that 32-bit UID support probably won't be added to ext2
until it gets some other major overhauls. In any case, the kernel itself
needs to support 32-bit UIDs before this can happen.
Thank you very much for your time,
Chris Wing
wingc@engin.umich.edu
-
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/