Re: Issue 9.2) <steal-lock>

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Mon, 15 Dec 2003 10:57:11 -0400, William Caban <william@hpcf.upr.edu> said:

William> What about an attacker issuing the <steal-lock>?

The goal was, and it should be documented in the document, that the
steal-lock operation would only be configured for use by
root-equivalent operators.  It allows the lock function to be given to
"lower" operators but reserves a fallback to the upper ones.

William> Isn't this still being a DoS possibility? I understand the
William> <steal-lock> operation but I'm not sure it will solve what we
William> are trying to resolve.

The technically proper solution would be to not allow users to lock
portions of the configuration they don't have write access too.
However, this notion of more fine-grained locking was not desired by
the WG.  (Note that implementing a global lock that only locks
configuration portions you're allowed to modify is significantly
easier than a true fine-grained lock.  However, the WG decided (at
multiple meetings) that this method was within the desired operation
set for the protocol.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
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/>