[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: partial locking and access control
Martin Bjorklund wrote:
Andy Bierman <ietf@andybierman.com> wrote:
Hi,
The requirement about 'must have enough access rights'
to get a partial lock is problematic.
In order to accept this requirement, I have to accept the fact
that NETCONF has a proprietary access control model, instead
of no access control model at all, and I don't.
The standard access control model in NETCONF is that every user has
access to every part of every configuration database.
Are you saying that in order to be RFC 4741 compliant, an
implementation MUST NOT have a (proprietary) per-user access control
model? That is definitely not my understanding, and I'd be very
suprised if any netconf implemention works that way.
No, I am saying that if you want to make a standard
for partial locking, that it can only rely on mechanisms
defined in standards.
Having an 'access-denied' error-tag in NETCONF that supports
proprietary access control models is not the same thing as
defining a requirement in a standard that assumes some
unspecified access control model will be in place.
(BTW, checking partial locks at configure time doesn't work
for nodes that match the Xpath expression at access time,
but did not exist at partial-lock config-time.
What do you mean "doesn't work"? When the XPath is evaluated, a node
set is returned. Those node are locked. This is the design. What
exactly "doesn't work"??
There are Xpath expressions that can specify nodes without parent
nodes. What if the agent adds nodes to the configuration database
(e.g., card insertion), which adds nodes that match such an
Xpath expression. Then a proprietary <edit-config-with-Xpath> RPC
is used to modify that node.
Also, what if another session issues a <partial-lock> that matches
this new node, but none of the nodes locked in the first partial-lock
RPC (by the other session). This new node would of matched the
original Xpath expression had it existed at the time.
When a manager application looks in the NETCONF monitoring DM
and gets all the partial lock information, how does it know
that this new node is not part of the partial-lock that
the agent says matches the lock request?
The config-time-only
for arbitrary Xpath approach is completely broken for this reason.)
Please clarify "completely broken".
A 2nd partial-lock request which matches a new node
is granted, even though it also matches the first partial-lock
that includes this new node in its Xpath expression,
but not actually in the partial-lock.
I think an operator issues a lock that matches the new node,
it expects the lock to work when access to the
locked data is requested, regardless of when the lock was granted.
/martin
Andy
--
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/>