Re: More confirmed-commit issues

[Wes Hardaker <wjhns1@hardakers.net>]

Andy> It is astonishing to Mgr B who has no way of knowing a revert
Andy> timeout is pending. To me, the whole thing is just fragile. 
Andy> IMO, a configuration protocol should be robust, not fragile.

Andy> A protocol that can allow the possibility of severely detrimental
Andy> config changes (through unintended or malicious acts), by merely
Andy> dropping a connection, is fragile.

Andy> It's possible the security AD could have a problem with this
Andy> too, during the IESG review.

It's in line with all the other similar problems I've already
expressed so I wasn't going to bring it up.  confirmed-commits
actually exasperate something that already exists in the
global-config-store and locking problems.  Previously it was
acknowledged that you should always use locks to avoid multiple people
modifying parts of the config at the same time when all of a sudden
neither has the ability to actually perform a commit because the
permissions of either don't include all the changes that would be
required during the copy.  With a confirmed commit if the locking
session is lost intentionally or due to (potentially temporary)
network issues caused by the commit a second user could actually come
in, make a minor change to either running or candidate that would
prevent the original person from being able to roll back in the first
place.

Since that was impossible to follow in text:

  X = 1
  Y = 1

  A can modify X but not Y
  B can modify Y but not X

  A locks candidate
  A locks running
  A changes X=2 in candidate
  A issues confirming commit, timeout = 60
  A's session closes, losing both locks

  B opens session
  B modifies Y=2 in running
  B closes session

  A does *not* send a confirm

  At commit-time + 60, the box should revert running to X=1 Y=1 but
    can't because A doesn't have permission to change from current Y=2
    to Y=1.

Discussion of multiple overlapping confirming-commits left to the reader.

One alternative is to say that locks last even beyond the session
closure until the confirmed commit timer is finished.  That has other
ramifications too, but probably less-so.

I've said before that the notion of shared scratch spaces really makes
the protocol a root-only kind of protocol.  Many of these security
problems would go away if things were done via "delta"s instead of
all-or-nothing from a shared space.

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