PERFORCE change 20657 for review
Brian F. Feldman
green at freebsd.org
Mon Nov 4 21:07:59 GMT 2002
Robert Watson <rwatson at freebsd.org> wrote:
> On Mon, 4 Nov 2002, Brian F. Feldman wrote:
>
> > Brian Feldman <green at FreeBSD.org> wrote:
> > > http://perforce.freebsd.org/chv.cgi?CH=20657
> > >
> > > Change 20657 by green at 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 at FreeBSD.org <> bfeldman at tislabs.com \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
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