The patches are available at:
http://www.engin.umich.edu/caen/systems/Linux/code/misc/2.3/19991210/
Changes in this version:
- updated to Linux 2.3.32pre2
- removed many of the "#ifdef UID16_COMPAT_NEEDED"s in the code by
using macros to clean things up (Ben LaHaise's suggestion)
- system call numbers changed to move out of the way of
truncate64() and ftruncate64().
( NOTE: this will happen again )
It is tested and working on the i386 architecture.
I also have a test version of the new glibc patch available. You
can download it from:
http://www.engin.umich.edu/caen/systems/Linux/code/misc/2.3/19991210/glibc-2.1.2-highuid.patch
This should apply cleanly to glibc 2.1.1 or 2.1.2. I've tested it with the
glibc 2.1.1 package in Red Hat 6.0. There is still one problem involving
getegid() and saved gids; one obscure program I wrote breaks, and I
haven't found the bug yet.
Other than that, it seems to work fine and can run on kernels with or
without the 32-bit UID patch.
(Thanks very much to Andreas Jaeger for contacting me and helping me out
with the glibc issues)
Overall, I'm pretty happy with the state of the patches so far, and I'm
going to ask Linus about merging this very soon, starting with a little
bit of the architecture independent patch.
The open issues at this time:
- is it safe to assume that setuid(), setgid(), setfsuid(), and
setfsgid() will not be passed garbage in the upper 16-bits by
old libraries?
At present, I haven't created new 32-bit UID versions of these
calls, since I can already pass 32-bit UIDs to the existing
ones.
- what do the arm, m68k, sh, and sparc people think of my patches
for their architectures?
- the new SysVipc API needs to be 'set in stone'. I've made sure
that it will accommodate:
32-bit uid_t, gid_t, 32-bit pid_t, 32-bit mode_t,
4 extra machine words (unsigned long) in msq64_ds,
semid64_ds, shmid64_ds
Thanks,
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/