That's interesting, because not all the filesystems support high uids.
I wonder what happens to a setuid 65536 file on a minix V1 filesystem?
Last time I looked at 32bit uids, one of the problems was that uid_t
for structures on disk (eg. ELF coredumps) and __u16 had been used in
APIs, which makes the transition to 32bit uids a little painful.
Changing the existing interfaces without breaking existing code will
be an interesting experience. If the libc checks the kernel version
number, it can decide to use 32bit uids or 16bit uids for calling
system calls. What libc5 should do when it is given a uid >=65535 is
anybody's guess. I'm not in favour of this method - people are always
upgrading their kernel faster than their libc, and this will cause a
confusion.
Alternatively, we can just add new system for 32bit uids and have the
old interface translate be simple wrappers around the new code.
(cf: stat, oldstat, uname, olduname, oldolduname.) This would have the
advantage that statically linked programs (typically huge Motif
applications) would continue to work.
However it is implemented, if you want 32bit uids, it is worth putting
in the effort to design a migration plan for the transition from 16bit
uids to 32bit uids. If kernel interfaces need to be changed, it might
be sensible to push for a change now, even before there is any code in
the kernel to implement 32bit uids. On the other hand, it might not
be - I haven't thought through the consequences of changing uid_t.
> 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.
Many filesystems don't understand uids or the uid is just a mount
option (eg. adfs, msdos, devpts etc). They are trivial to fix and
probably already work with large uids anyway.
ext2 has spare space in the inode where the most signicant 16bits of
the uid can go. With luck, previous versions of the filesystem will
have required that the reserved fields are initialised to 0 when an
inode is allocated. The new process accounting records also have spare
space.
Some filesystems have 16bit uids and no spare space in the inode.
There are tricks you can do to layer 32bits uids on top of such a
filesystem, but if you need do things like that, you might as well just
replace the filesystem with ext2.
Things that need checking are:
- what happens when you use a 16bit fs with a uid>=65535?
- what happens when you use a system call with a 16bit uid when your
uid is >=65535.
- Does auth_unix pass credentials correctly? (I believe it does.)
- Is there suffient space for formatting uids in /proc?
It doesn't look like that much work to implement, but it's definately
a 2.3 project.
Peter
-
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/