From owner-p4-projects Mon Nov 4 13: 8: 2 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 9639A37B404; Mon, 4 Nov 2002 13:08:00 -0800 (PST) Delivered-To: perforce@freebsd.org Received: from green.bikeshed.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id EC08B37B401; Mon, 4 Nov 2002 13:07:59 -0800 (PST) Received: from green.bikeshed.org (rqxyz6n4txgngk6u@green.bikeshed.org [10.0.0.1] (may be forged)) by green.bikeshed.org (8.12.6/8.12.6) with ESMTP id gA4L7x56078071; Mon, 4 Nov 2002 16:07:59 -0500 (EST) (envelope-from green@green.bikeshed.org) Received: from localhost (green@localhost) by green.bikeshed.org (8.12.6/8.12.6/Submit) with ESMTP id gA4L7xhg078068; Mon, 4 Nov 2002 16:07:59 -0500 (EST) Message-Id: <200211042107.gA4L7xhg078068@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Robert Watson Cc: "Brian F. Feldman" , Perforce Change Reviews Subject: Re: PERFORCE change 20657 for review In-Reply-To: Your message of "Mon, 04 Nov 2002 15:57:51 EST." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 2002 16:07:59 -0500 Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > On Mon, 4 Nov 2002, Brian F. Feldman wrote: > > > Brian Feldman wrote: > > > http://perforce.freebsd.org/chv.cgi?CH=20657 > > > > > > Change 20657 by green@green_laptop_2 on 2002/11/04 11:34:53 > > > > > > Be resilient to relabel operations on mac_lomac objects by > > > always blanking the destination and copying the old label, > > > but only if the new label "appears" internalized. > > > > BTW, this really does apply to all policies, and needs to be documented > > as such. Biba/MLS got it "not totally wrong" because they don't bzero > > the label they're overwriting, so in the case where there's nothing to > > copy they just overwrite nothing on the target label. > > I guess I would interpret the Biba and MLS behavior a little differently: > Biba and MLS labels optionally have 0, 1, or 2 of their components defined > (single, range). Biba and MLS will avoid updating any component that > hasn't had an update requested, and the conditional copy implements this > behavior. I.e., if you don't request single be updated, it won't replace > the single component. That representation does coincide with the > initialized and not internalized/created definition intentionally -- are > you suggesting that we just need to add a comment indicating as much, or > that we need to change behavior? It's not immediately obvious, nor is it even obvious upon deep inspection, what the right behavior is supposed to be without the correct documentation there. I don't think making things like this completely implicit is helpful in the understanding of these policies, so some sort of documentation in the code really needs to occur, in my opinion. I think adding a specific "relabel" helper function which documents the assumption being operated upon is the best way to go. Then again, I'd prefer to not have an initialized, non-NULL label passed into unsuspecting policies, but I know that's not something you want to try to do now :) -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message