PERFORCE change 32072 for review

Adam Migus amigus at migus.org
Fri May 30 13:42:23 GMT 2003


Robert Watson wrote:

>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
>
>
>  
>
Robert,
Ok, so let left = the maximum string length constant you defined,
instead of size with the original code.  Do the math at the end to
calculate any discrepancy.
The problem's solved, the snprintf() semantics are preserved and
your original fix is again redundant.

Adam

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



More information about the trustedbsd-cvs mailing list