Date:   Tue, 9 Nov 1999 20:42:47 -0500 (EST)
From:   Chris Wing <wingc@engin.umich.edu>
To:     torvalds@transmeta.com
Subject: [PATCH] 32-bit UID support for 2.3.27pre2 (proposal)

Linus and all:

Over the past year, I've been patching Linux to support 32-bit UIDs in
response to the needs of my university. At the same time, after hearing
interest from vendors and other people around the world, I've wanted to
help make 32-bit UIDs a standard feature in Linux. I meant to submit a
patch for 2.3 much earlier than now, but after the feature freeze, I
mistakenly thought that it would be better to wait for 64-bit file support
to be merged (presumably in 2.5), and try and get 32-bit UIDs included
alongside. This way, glibc would not have to support 3 different kernel
APIs (regular, 32-bit UIDs, and 32-bit UIDs+64-bit files).

Anyway, after I discovered that 64-bit files were indeed being merged into
2.3 (I've corresponded with Ben LaHaise), I realized that it would be
worth a shot to see if 32-bit UIDs could be included as well. I apologize
for not sending this earlier.


I have written patches that add 32-bit UID support to 2.3 as cleanly as
possible. I've broken them up into separate areas of interest so that you
don't have to wade through a huge chunk to see what I've done.

The patches are available at:

http://www.engin.umich.edu/caen/systems/Linux/code/misc/2.3/19991109/

linux-arch-independ.patch - architecture independent patch which adds
			    necessary backwards compatibility 16-bit UID
			    system calls, within #ifdefs so that the extra
			    code is only built on platforms where it is
			    necessary.

linux-ipc.patch	- this fixes up the msgctl(), semctl(), and shmctl() calls
		  to deal with 16-bit UIDs when communicating with user
		  space. (the kernel still uses 32-bit UIDs internally)

		  This patch has been separated from the above since it is
		  necessarily a bit large.

linux-ext2.patch - this implements 32-bit UIDs in the ext2 filesystem,
		   using the same inode layout as the HURD. They are
		   enabled by default, but can be disabled on a
		   mount-by-mount basis with a mount option.

linux-filesystems.patch - this fixes up various filesystems to not write
			  truncated UIDs to disk (minix, qnx4, sysv), and
			  enables the use of 32-bit UIDs on ufs and udf,
			  which presently have them intentionally
			  disabled.

linux-other-arch.patch - this adds 2 lines to the include files for those
			 architectures which already use 32-bit UIDs
			 (alpha, mips, pps, sparc64).

The rest of the patches add the necessary new system calls on an
architecture by architecture basis:

linux-arm.patch
linux-i386.patch
linux-m68k.patch
linux-sh.patch
linux-sparc.patch

The added system calls are: lchown(), getuid(), getgid(), geteuid(),
getegid(), setreuid(), setregid(), getgroups(), setgroups(), fchown(),
setresuid(), getresuid(), setresgid(), getresgid(), and chown().


The central premise of the architecture independent patch is that it is
better for the kernel to use a fixed value when trying to fit a UID or GID
that exceeds 65535 into a 16-bit slot, rather than just use the low 16
bits. This shouldn't be taken as a security feature intended to prevent a
process from assuming that UID 65536 is 0, but rather as a convenience
feature to help find out which programs are using the old system calls.
(you can add a user called "overflow" to your password file with that UID
and notice whenever it comes up) There are 4 such fixed values that are
used in the case of an overflow: a UID/GID which are returned by system
calls to processes, and a UID/GID which are written to filesystems that
can only use 16-bit UIDs. They are all tunable via sysctls and default to
65534.


These patches should provide 'perfect' backwards compatibility for all
programs, with the exception of:

	- binary kernel modules (but that's not supposed to matter,
	  right?)

	- binary emulation of other OSes may break-- this could affect
	  iBCS as well as the sparc32 userland in sparc64.

Things that are left to do (but which shouldn't by themselves be viewed as
a reason why the current patch is not suitable for the kernel):

	- new msgctl(), semctl(), and shmctl() system calls are needed
	  that are capable of handling 32-bit UIDs

	- support for 32-bit UIDs in the real time signals' siginfo
	  structures. Hopefully, this can be done by using some of the
	  existing pad space (this is the same thing that Robert de Vries
	  wants to do with his POSIX timers)

These patches have been tested with 2.3.27pre2 on i386 and do work. We
have been using similar patches for over a year out of necessity (we have
130,000+ user accounts and a shared file system).

To see the patches work, you can try rebuilding glibc2.1 with the
following patch:

	http://www.engin.umich.edu/caen/systems/Linux/code/misc/glibc-2.1.1-highuid.patch

and the resulting C library will allow all glibc programs to use 32-bit
UIDs without a recompile (make sure before building glibc that
/usr/include/linux points to the patched version of the Linux sources for
32-bit UIDs and your architecture).


If you think that the central patches are good, I will of course send the
rest of the patches (architecture and filesystem updates) through their
respective maintainers.

I am willing to make any changes necessary to these patches, if there is
any chance of them getting included before 2.4. Please let me know if
there is anything that I can do.

Thank you very much,

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/