Date: Mon, 04 Nov 2002 16:07:59 -0500 From: "Brian F. Feldman" <green@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: "Brian F. Feldman" <green@freebsd.org>, Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 20657 for review Message-ID: <200211042107.gA4L7xhg078068@green.bikeshed.org> In-Reply-To: Your message of "Mon, 04 Nov 2002 15:57:51 EST." <Pine.NEB.3.96L.1021104155537.19506G-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson <rwatson@freebsd.org> wrote: > On Mon, 4 Nov 2002, Brian F. Feldman wrote: > > > Brian Feldman <green@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211042107.gA4L7xhg078068>