Date: Wed, 06 Jun 2007 12:02:44 -0500
From: Rich Brown <Rich.Brown at sun.com>
Subject: Re: 2007/315 [Extensible Attribute Interfaces]
Glenn Skinner wrote:
>
> Suppose someone desires to add a new "system" attribute. By what
> criteria can we (the ARC) judge whether that attribute qualifies
> as being a "system" attribute? That is, what constitutes
> "systemness" in an attribute?
I believe that if an operating system module needs to use the value
of an attribute to make a decision, then that attribute is
considered a system attribute.
Let's probe this characterization a bit.
At first glance, this just seems to move the question to what
constitutes an operating system module. Does this mean somethng that's
part of the kernel's address space? Or (as was suggested during
today's PSARC meeting) does this mean something that's part of the
trusted computing base?
Consider, for example, a third party HSM that wants to maintain an
attribute that records an offset beyond which the file's data is staged
out to tertiary storage. Is this a system attribute? Depending on how
the HSM is implemented it may or may not be interpreted by code
residing in the kernel address space. The HSM will almost certainly
require some level of elevated privilege to operate successfully. Does
that push it into the trusted computing base? If we decide the
attribute does qualify as a system attribute, would or should the HSM
vendor need to get ARC approval for the attribute name and to have it
live alongside the other system attributes?
Questions like these make me uneasy about introducing a potentially
open ended set of "system" attributes. The ones proposed as part of
this case all seem (more or less) reasonable. But the case also
outlines a scheme for extensibility. I would like the bounds for what
qualifies for inclusion to be as clear as possible. (And for extra
credit, I would like that hypothetical third party HSM vendor to be
able to deliver product without having to visit PSARC.)
-- Glenn
