posix1e level of adherence

[Robert Watson]

On Mon, 19 Nov 2001, Andrew R. Reiter wrote:

> I am currently going through an kind of posix.1e-ifying some of my
> already done work.. Yet as I go through it I continue to dislike some of
> what posix1e does and am having a tough time convincing myself to follow
> it at all times.  We've discussed this before, but since capabilitiies
> and acl's are ahead of audit, I was wondering if you could briefly let
> me (and us)  know of the level of commitment you have with the posix1e
> guide.  Specific information such as whether or not you just comply with
> the guideline for certain functions, certain data types, and/or other
> odds and ends would be awesome. 

Sure. :-)

In general, it's nice to follow POSIX.1e, because that encourages
portability.

Sometimes, the description of a feature provided in POSIX.1e is both
feasible and useful to implement.  In those cases, we strive for maximum
compliance, and carefully document any non-portable concerns.  An example
of this is the ACL spec, where there are few differences between the
implementation and the spec.

Sometimes, the description of a feature provided in POSIX.1e is useful,
but because there was limited deployment of the features as specified,
there are ambiguities or conflicts that must be resolved in
implementation.  In those situations, it's desirable to maximize
compliance, where it makes sense, maximizing portability and usefulness
otherwise.  An example of this is the Capability spec, which is largely
useful, but some pieces of behavior require clarification from the spec.
The POSIX.1e mailing list has traditionally been a good place to do this.

Sometimes, the description of a feature provided in POSIX.1e is not
useful, in which case the logical choice would be to skip out on POSIX1e,
and possibly consider other types of portability choices.  For example,
the information labeling and MAC interfaces either describe a feature
we're currently not interested in (or has limited utility), or describe an
interface to that feature that is insufficient to support our
requirements.  In those situations, it is fine to diverge from the
specification substantially, but it's also a good idea to look at the
approach taken in other platforms, so that we can adopt ideas from there
where possible (and maybe even accomplish portability).

I assume, because of your interests, you're refering to the audit spec. 
You'll notice that I carefully avoided using it as an example: the reason
for this is that I can't decide what category to put it in, and I've seen
conflicting views on the topic.  In the two implementations I've worked
on, I've looked at two different approaches: (1) implement the kernel and
userland code driven by the description in the specification, and (2) 
implement the kernel code based on performance and other optimization
points, and wrap it with userland code to make it look like the spec. 
Both of those approaches are legitimate.  If you have specific concerns
about the audit spec, it might be worth raising them on the POSIX.1e
mailing list. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services




To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message