[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Methods, data hiding, and friends

Juergen Schoenwaelder a écrit :

On Sat, Nov 04, 2006 at 01:04:40AM -0500, David Harrington wrote:

In netconf, a capability's method such as "create-vlan" may need to
manipulate the data elements of other capabilities, such as the
interface capability. Will methods of one capability be permitted to
directly modify the data of another capability, or will they be
constrained to utilize public and friend interface methods of the
other capabilities?


Netconf has evolved to take two different views of the world:

(1) A document-centric view where you use primitives like the powerful
    edit-config operation to make changes on a document describing a
    configuration.

(2) A function-centric view (or {method/operation/procecure/command}
    -centric view if you like these terms better) where you use
    special RPCs to invoke a certain function.
As a consequence, I believe we need to have an access control scheme
which supports a document-centric view and a function-centric
view.

The question was raised whether the access control for the
function-centric view is also subject to the access control for the
document-centric view (or view versa although people did not mention
this yet) and my personal answer to this question is "no". A function
"create-vlan" performs a certain well defined operation and I either
grant access for someone to perform this operation or I don't. The
value of a function such as "create-vlan" is that it hides the
implementation details and objects affected and I fear we loose the
benefits of hiding the details once we end up specifying which
"objects" are involved in the execution of such a function for access
control purposes.
I fully agree. If people define new operations which have impact on the same objects as edit-config, they will probably need to specify for these operations the objects on which you need "write" privileges in order to perform a consistent access control. This can be done but it is one more constraint. If you have a dual access control, one for document-centric and one for function-centric, you introduce an important risk of inconsistencies.
What people can do also (since all implementations must support edit-config) is to generate an edit-config for this operation (like create-vlan) locally in the agent. And perform access control on it as for all edit-config operations. I think the function-centric approach should rely on the document-centric approach not only to avoid such access control mess, but also to have a single entry point for editing the configuration datastore. In most cases, such functions are typically macro-operations that can be decomposed into several atomic operations.
(Note that you could also have a create-vlan button and generate this edit-config on the manager side. This avoids to define new operations and also consumes less CPU in the agent side...) 



Sure, this approach opens a window for "interesting" access control
configurations where "side effects" may be used to achieve something
using the function-centric view which you are not allowed to do via
the document-centric and vice versa. (For example, you disallow the
usage of the "create-vlan" function for some principal but the same
principal may still be able to create a vlan by playing with
"edit-config".) I assume that the price on the agent side for
preventing such situations is going to be high and thus I prefer to
push the handling of such situations to external tools that can
analyze and reason about access control rules. (Note that this is not
really something new. Even in the SNMP world, if I prevent access to
the interface table, someone might still create a VLAN interface using
her write access to the Q-BRIDGE-MIB::dot1qVlanStaticTable.)

BTW, I would like to have the flexibility to give one principal only
access to the document-centric view and another principal only access
to the function-centric view of a box. I believe that applications
(and most humans) will prefer one of the two views for a given task.
What do you mean by most humans ? management application developers ? or human managers ? If you mean "developer", the implementation choices (driven by simplicity reasons) will affect the privileges of the manager... It does not make sense. If you mean "manager", I don't think a manager will ever write XML requests by hand, and therefore will never have to make a choice for document-centric or function-centric approach.
On what criteria can you decide that a principal has access to the document-centric or function-centric view ? 



To create vlans, you likely prefer a "create-vlan" function; for
saving/restoring configs or for pushing a tested config change to many
boxes, you likely prefer edit-config. For testing config changes, you
might again prefer a function-centric view.
(IMO) In any case, the time when you translate the conceptual "create-vlan" to low level operations should happen before access control process. Otherwise, you may have consistency issues. 

Regards,
Vincent


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>