Glenn Skinner wrote:
> 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
>
In determining if an attribute should be considered a system attribute
or should simply follow the current (opaque) extended attribute model,
there will be black-and-white cases and there will be gray areas.
For those gray areas, the project team's advice to the ARC is to
challenge any proposal for new system attributes with the following
questions:
- Do operations on the file itself (e.g., open, read, write, close,
unlink) cause the file system to modify the attribute? If so, then
it's a system attribute.
For example, writing to the file would cause the file system to set
the AV_MODIFIED attribute.
- Does the file system that implements the attribute make decisions based
on the value of that attribute? If so, then it's a system attribute.
For example, the file system will not allow a caller to write to
anywhere but at the end of a file if the file has the APPENDONLY
attribute set.
- Does the kernel need to protect the format and/or value of the
attribute for the value to be useful to consumers other than the one
that set the value? If so, then it may be a system attribute.
For example, CREATETIME must be in a time format (timestruc_t).
- Is there a precedent in another operating system for the attribute
being a system attribute?
For example, on FreeBSD the NODUMP attribute is stored as a bit in
the UFS inode and can be retrieved with stat(2) by ufsdump.
- If all else fails, what justification does the project team have for
proposing an attribute to be a system attribute as opposed to an opaque
attribute?
There may be legitimate reasons for proposing that an attribute be a
system attribute. For example, an anti-virus facility integrated
into Solaris might require a "scanstamp" to be stored as a system
attribute for the following reasons:
- If the virus-scanner needed to check the scanstamp on every
open, that means each open must do an open and read on the
extended attribute file containing the scanstamp which would
be a severe performance penalty.
- Storing the "scanstamp" as an extended attribute might be
prohibitive since the file being scanned could itself be an
extended attribute file. Recall that extended attributes on
extended attributes may not be supported depending on the
implementation. (See section 4.6 on the opinion for PSARC
1999/209).
... and we're not going to get that extra credit unless, of course,
the hypothetical vendor agrees to using the existing (opaque) extended
attribute facility. Changes to support new system attributes will touch
enough to justify PSARC attention.
Rich
