Messages in this thread | | | Subject | Re: High UID support for Linux | Date | Fri, 20 Nov 1998 14:18:13 +0200 (EET) | From | Matti Aarnio <> |
| |
> Has anybody looked seriously at supporting 32 bit UIDs on Linux? We'd > really like to make Linux a commodity at Umich, but with a user base of > about 100,000, high UIDs are an absolute requirement. I've only just > started looking at this, but scanning the include files, it would appear > that some platforms already support high UIDs, but not i386.
I think the topic has had some recent discussion -- like one or two months ago.
There are three problems: - userspace 16/32 bit UIDs - kernelspace 16/32 bit UIDs - user/kernel interface
To avoid an extremely unpleasant piecemal shifting from limited value- spaces to less limited ones, I would suggest that in 2.3 we will do a large-scale overhaul of the interfaces to do 32-bit UIDs/GIDs, and 64-bit file offsets. I am sure there are also some other similar issues lurking around. (a bit more on this below.)
No, it won't happen in 2.2 for i386. Alpha has 32-bit UIDs, but that is mostly because of ABI compability with DEC UNIX, which has 32-bit UIDs..
The overall UID-size list is:
alpha u32 arm u16 i386 u16 m68k u16 mips s32 (?) ppc u32 sparc u16 sparc64 u32
Comparing i386 vs. Alpha /usr/src/linux/include/asm-*/posix_types.h files shows at least following items to have size questions:
dev_t u16 u32 /* Need someday u64 ? */ mode_t u16 u32 /* no need to change ?*/ nlink_t u16 u32 /* no need to change ?*/ ipc_pid_t u16 s32 /* no need to change ?*/ uid_t u16 u32 gid_t u16 u32 off_t s32 s64 size_t u32 u64 ssize_t s32 s64
__kernel_loff_t s64 s64 /* already usefull size */
Some people are asking support for things like 100 000 processes, while the current code inside kernel/fork.c does lots of assumptions about limit being 32 000 processes, so:
pid_t s32 s32 /* Need someday s64 ? */
but that will require user-space tools modified a bit, too. (Things like 'ps' and 'gdb' commands, to name a few.)
> Just for grins, I tried changing the typedef in linux/types.h and > recompiling the kernel. Wouldn't even boot. Then I noticed that the > uid and gid fields in ext2 inodes are 16 bits. So it seems like this is > a project, not than a hack. (This was on 2.0.35.)
Depends what you mean with 'boot', or starting user-space programs, like '/sbin/init' ?
Extending EXT2 fs uid-spaces is trivial, once the interface issues to user-space are resolved (and all new binaries are in use which use 32-bit uids..)
> There's enough interest in this on campus that we can throw some > resources at it. If no one else has this one, we could probably do it. > If someone is doing it, how do I get in touch? Comments? Advice
You will need to do magics into glibc-2.0.100+ to support it, possibly implement sysconf(2) into i386 to allow easier way for the library to find out if the kernel supports larger uid_t value scope, than that of the classical default.
There are lots of calls which pass around uids and gids (as parameter values, or components of a struct), all those will need at least two alternate forms.. (Alternate call vectors?)
You could (perhaps) do it even via personality() syscall. See values/flags from <linux/personality.h>. (How do you do the backwards compability, that is the crux..)
> Regards, > Jon > ---------------------------------------------------------------------- > Jon Leonard jbwl@umich.edu > CycleStealer, School of Information, Umich +1 (734) 936-7255
/Matti Aarnio <matti.aarnio@sonera.fi>
- 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/
| |