OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Postfix Archives: Re: 64K User Barrier on Linux

Re: 64K User Barrier on Linux

Andrew McNamara (andrewmconnect.com.au)
Fri, 26 Nov 1999 10:41:03 +1100

>> The filesystem. Ext2 uses a 16-bit datum for UID and GID.
>
>The man is right. I suppose this limits Linux usability as a big
>NFS server.

Here's a message from Theodore Y. Ts'o, the ext2 maintainer, on the
subject:

Date: Sat, 21 Nov 1998 00:35:42 -0500
To: jon.leonardumich.edu
Cc: linux-kernelvger.rutgers.edu
From: "Theodore Y. Ts'o" <tytsomit.edu>
Sender: owner-linux-kernelvger.rutgers.edu
Subject: Re: High UID support for Linux
In-Reply-To: Jon Leonard's message of Thu, 19 Nov 1998 17:38:39 -0500,
             <36549DEF.1E8F26EEumich.edu>
--------

   Date: Thu, 19 Nov 1998 17:38:39 -0500
   From: Jon Leonard <jbwlumich.edu>

   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.

   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.)

The ext2 inodes are the smallest part of the problem; there is already
space reserved in the node for the high bytes of the uid and gid
(although every so often I have to tell someone "no" when their favorite
ext2 patch wants to steal those bytes from the inode for their own
purposes).

The harder thing to do is creating the a system call which returns a
new stat structure, and then modifying libc to know about this new
system call --- if it happens to be there.

And of course, checking for all of the other places in the kernel which
might break when changing the size of the uid_t. I'm actually surprised
the your kernel didn't boot, but there may have been some assembly
language part of the kernel which is dependent on the 16 bit uid.

Anyway, this sounds like a great 2.3 project. I don't think it's
actually that hard, especially since glibc's stat already supports the
32-bit uid.

                                                - Ted

This archive was generated by hypermail 2.0b3 on Thu Nov 25 1999 - 17:42:04 CST