From owner-p4-projects@FreeBSD.ORG Fri May 30 06:43:02 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id AF0C737B404; Fri, 30 May 2003 06:43:01 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4868437B401; Fri, 30 May 2003 06:43:01 -0700 (PDT) Received: from garple.migus.org (pcp243563pcs.howard01.md.comcast.net [68.55.84.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 422C943F3F; Fri, 30 May 2003 06:43:00 -0700 (PDT) (envelope-from amigus@migus.org) Received: from migus.org (ganyopa.migus.org [192.168.4.2]) by garple.migus.org (8.12.7/8.12.7) with ESMTP id h4UDgwZ3009110; Fri, 30 May 2003 09:42:58 -0400 (EDT) (envelope-from amigus@migus.org) Message-ID: <3ED75FBF.2080302@migus.org> Date: Fri, 30 May 2003 09:42:23 -0400 From: Adam Migus Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030302 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-28.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: perforce@freebsd.org Subject: Re: PERFORCE change 32072 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2003 13:43:02 -0000 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@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