PERFORCE change 32072 for review

[Robert Watson]

On Thu, 29 May 2003, Adam Migus wrote:

> So my mistake was essentially neglecting to account for an intentionally
> inappropriate action by a userland process.  My apologies.  Sometimes I
> overlook these things.  Perhaps a better fix might be checking if left
> goes negative and barfing if it does? 

Yeah, there are two parts to the problem:

(1) Failure to handle a particular return mode in snprintf() based on an
    incorrect assumption about an argument.

(2) When (1) occurs, failure to maintain the semantics the caller expects
    -- i.e., the real snprintf() semantics.

The current code is largely fine with the minor correction I made, except
that we now need to return the real value of len, not the adjusted value.
I.e., it's fine for us to truncate, but we have to return the desired
size, not the computed size, or the caller can't detect the truncation. So
the second element of the fix is not to recaculate len for the purposes of
trimming the last '+' off the list.  The temptation would be to switch to
a model where we append '+x' rather than 'x+' each time except the first
time, avoiding the issue and keeping a running sum.

Part of the problem with the snprintf() model is that it takes the
approach that the caller can't easily calculate the amount of space needed
for the string without calling snprintf().  We do want to keep elements of
this approach because the point of abstracting, say, label element
conversion to a string, is that we've abstracted a common element, both
inside the Biba and MLS policies, between the MAC Framework and the policy
modules, and between userspace and the MAC Framework.  The current
approach was relatively robust as long as policies could perform a
conversion to string in a single call to snprintf(), since then they just
wrapped it (hence the comment).  With the necessary addition of
compartments, that's no longer the case.  As I mentioned in an earlier
e-mail, a more robust approach would be to use sbuf's, but that's too
large a change before 5.1-RELEASE.  We'll move to sbuf's once 5.1 is
branched, and detect the out-of-space event on the transfer back to
userland, rather than in numerous places during the assembly. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message