David Powell wrote:
> Scott Rotondo wrote:
>
>> 4. Privilege names, at least, cannot be considered as implementation
>> details that are subject to change within an RBAC profile because the
>> specific privileges are documented on the man pages of system calls
>> that require them. Although this argument does not apply to
>> authorizations, I think they should be treated similarly for the
>> reasons described above.
>
> But which system calls a command uses to accomplish something are
> themselves implementation details. It's then our choice whether we
> expose the privileges those system calls require as privileges the
> command requires, or we expose an abstraction that hides the
> underlying authorization mechanism.
>
> In other words, though our choice of interface might restrict the
> system calls we are allowed to use, the choice of system calls
> doesn't necessarily impact how the command is presented to the user.
That's a valid point. However, for commands that use privileged system
calls, I think we will need to document their required privileges if we
want others to be able to create new entities (such as RBAC profiles and
SMF actions) that use the commands.
Incidentally, did I correctly infer that the future coreadm will require
*only* authorizations (because it will store all state in SMF properties
rather than files that require privilege to write)?
>
>> Having said all that, this is a general architectural issue that
>> should not hold up the current fast-track. PSARC members: What is the
>> best mechanism to reach consensus on this issue and ensure that
>> current and future documentation complies with that consensus?
>
> I don't have a problem with documenting the Authorizations; the
> reasons for doing so do make a lot of sense. I look forward to your
> guidance regarding how the different authorization mechanisms should
> documented.
>
PSARC members: How can I best propose, and get approval for, such
guidance? Should this be a "best practice" submission?
Scott
