> 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.
It's a pain but their is a continual ongoing pain coming from
the 16 bit UID/GIDs. I hear about someone saying something about "oh,
I found a security hole in Linux, just get a user with UID 131072 and
see what happens" just about as often as I get "good times virus" warnings.
Hint - it becomes an alias for UID 0 that some security scanners don't
detect and doesn't show up on password file consistancy checks as a duplicate
id and even a casual review of the password file doesn't immediately warn you
unless you are into remembering high powers of 2. It's not a real serious
problem since someone obviously has to create that user to begin with.
It use to be a cute trick to use UID 131072 over NFS and some implimentations
of NFSD on 16 bit UID systems would fail to spot this as root and fail to
map it as nobody and give the client "root" priviledges (not present in
Linux implimentations unless someone screws up and reintroduces and old bug).
> 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.
It's needed... It make break a few things at first, but this won't
be the first time that's been done and it won't be the last time.
> Peter
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- 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/