> 2.1. Omission of GNU su(1M)
>
> Although upstream open source software can be integrated with
> waivers on various policies surrounding internationalization or
> accessibility, security policies cannot be waived. Although the
> current implementation of GNU su is undoubtedly well-tested, it does
> not interact with PAM or BSM auditing and therefore would introduce
> | a setuid-component in violation of architectural policies [3, 4].
> | It is therefore omitted from the delivered components.
IMO, it would be valuable to state other precedents and policies
that, though not directly related to the commands of this case,
they may apply to other similar cases. VIZ:
PSARC/1999/555 Getting with the Freeware Program
PSARC/2000/488 Solaris/Linux Commands Compatibility and
PSARC/2005/185 Enabling serendipitous discovery
(possibly others I don't recall)
http://opensolaris.org/os/community/arc/policies/shared-sharable/
http://opensolaris.org/os/community/arc/policies/libraries/
http://opensolaris.org/os/community/arc/policies/SMF-policy/
http://opensolaris.org/os/community/arc/policies/NITS-policy/
http://opensolaris.org/os/community/arc/policies/PAM/
http://opensolaris.org/os/community/arc/policies/audit-policy/
(and possibly other policies and guidelines)
> 3.1. Non-conflicting commands.
>
> Location Uncommitted
> Invocation Uncommitted
> 3.2. All commands.
> Location Uncommitted
> Invocation Uncommitted
I'm not sure how to read this. Is this saying that the commands
syntax and symantics for that syntax will not change in an
incompatible with within a Minor release even if the community
changes? If not, and the intent is to track the community even
for incompatible changes, perhaps Volatile would be a better taxonomy.
If the intent is Uncommitted, why wouldn't Committed be more
appropriate? If the intent is that Sun build Committed interfaces
upon these interfaces, I suspect an underlying taxonomy below
Committed will require the same work to track in either case.
Gary..
