lkml.org 
[lkml]   [2000]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] 32-bit UID support for 2.3.36
	Ok...  Time for me to chime in...  :-)

On Thu, Jan 06, 2000 at 11:11:56PM +0000, Alan Cox wrote:
> This looks pretty nice now. One big glitch though. The syscall patch renames the existing
> syscall entry points. Don't do this as it breaks stuff and makes it hard to be sure that
> old code calls the right one (eg rebuilding libc5). Name the new ones things like
> sys_chown32(). It isnt like the glibc names and kernel names must match

I've glanced over the 32 bit UID stuff. I would desparately love
to see this in the kernel for a multitude of reasons, one of which is
security related. (I also have at least one situation where we are
legitimately looking at many times more users than 16 bits would allow.)

In the past there has been problems with the disparity between
16 bit UID systems and 32 bit UID systems over NFS. The classical problem
occurs when some clown on a 32 bit system adds a user id of 65536 (or
some other multiple of 2**16) and the 16 bit system fails to recognize
the UID as being zero in the low order bits resulting in root access to
a system that would otherwise not have root access.

AFAIK, Linux systems are NOT vulnerable to this. The user land NFS
daemon doesn't seem to be, but I don't know about the knfsd. A glance at
it didn't seem to reveal whether it would be or not. It's possible the
check on the !cr_uid check in auth.c will catch this, if it is post
conversion to 16 bits. If so, it will be clean once it's converted to
32 bit uid's as well. I just want to make sure people are aware of this
gotcha and we don't have any hidden sillyness where someone checks the
low order 16 bits for zero and then breaks on 32bit <-> 32bit mapping once
we dump the 16 bit limitation once and for all.

16 bit uids in NFS have been a sporatic problem from a security
standpoint and some NFS implimentation have code specifically to spot this.
If any of the Linux NFS code has this, it needs to be backed out when we
go to 32bits or legitimate UIDs which are multiples of 2**16 may get
incorrectly mapped.

I didn't see anything in the 32 bit UID patches that pretained to
NFS. Maybe, hopefully, nothing is required. That would be a GOOD thing.
I just want to make sure. :-) Because I really REALLY would like to
see 32 bit UID's in 2.4 and working correctly! :-)

Mike
--
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (770) 331-2437 | 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.050 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site