Skip site navigation (1)Skip section navigation (2)
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>