Date: Wed, 16 Oct 2002 09:46:09 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Maxim Sobolev <sobomax@FreeBSD.ORG>, "Danny J. Zerkel" <dzerkel@columbus.rr.com>, "Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info" <vova@express.ru>, freebsd-arch@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: short uid/gid Message-ID: <3DAD97D1.DB378D6B@mindspring.com> References: <Pine.NEB.3.96L.1021016084509.36711I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > I'm not convinced there's any value to providing the backward > compatibility that has to be asked for: the only benefit to the current > short-based API is that it allow serious security holes while not > following the standard API offered by other platforms (except Linux). The main benefit, to my mind, is standards compliance. The secondary benefit is ABI similarity for the purposes of supporting ABIs to run non-native software (e.g. Linux prior to 2.4). Binary backward compatability *demands* that you limit the range of your UIDs and GIDs to what will fit in a uint16_t, just as the recent issue with a pid_t exceeeding this size has damaged binary backward compatability with third party a.out binaries. > Freshly compiled applications should be using the proper types to > represent uid's and gid's -- if they're not doing that in the existing > code, they'll get truncated to the right size for "bug compatibility". If > they are using the correct size, they'll work correctly. To be able to > run properly on other platforms (vis Solaris), they already should be > using those types. Truncating of oversized values for credentials is Bad(tm), in that what you get is a different credential. The constraint has to be a priori enforced, or it's meaningless. > And it's not like the approach you've described makes it any easier to > implement: you still have to break out the old and new structures since > changing ipc_perm breaks the ABI for all of the System V interfaces, > rewrite the kernel code, etc. You might as well have added the > compatibility system calls since you still have to do all the mapping. His approach avoids the proliferation of system call entry points, which may conflict with those of other BSDs (among other things). BSDI limited the number of available additional FreeBSD system calls in a standardization effort a while back, if you'll remember, so a proliferation of calls is Bad. In addition, the compatability required this proliferation going forward. FWIW, I would agree with you, if you were advocating a cross-OS ABI definition of manifest constants, so that FreeBSD's new ABI, and, say, Solaris or Linux's ABI, were more congruent (you could get this without a new sstem call vector entry point, by using a different "ELF brand" value), but that's not what you are advocating. Also FWIW, my personal preference would be to follow the Solaris ABI; it's the least volatile of all ABI's in this area. In terms of the available applications, Linux is probably a better choice, but in terms of the amount of maintenance work required, Solaris is far and away the leader. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DAD97D1.DB378D6B>