Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-3380

Subversion authz model overhaul



    • Type: Improvement
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: trunk
    • Fix Version/s: 1.10-consider
    • Component/s: libsvn_repos
    • Labels:


      [An excerpt from my email to the dev@ list on this topic, found at
       See the full mail and resulting thread for details.]
      The Subversion security model is pretty simple.  You have paths, you have
      the ability to say whether those paths are readable, writable, both, or
      neither by anyone or any-specific-one.
      The Subversion change transmission model is also pretty simple.  You have
      the editor (svn_delta_editor_t) concept, which provides an interface for
      depth-first tree traversal, query, and modification.
      Finally, we have atomic commits.
      By themselves, these things are all Just Fine.  When put together, we start
      to see problems.
      The binding of a single editor drive with the atomic commit concept for
      commits means that for a single commit, you must use a single editor drive
      to touch not just all the things you want to change in the commit, but all
      the parents of those things up to and including their longest common
      ancestor path.  That becomes a problem when our security model's idea of
      "read access" is applied.
      Now, we can point the finger at any number of places here.  Some possibilies
         * Shame on the editor for requiring a depth-first tree drive that
           includes walking uninteresting parent directories.
         * Shame on the RA commit mechanism for binding an atomic commit
           operation to but a single editor drive.
      But here's where I think the real finger-pointing is best aimed:
         * Shame on the Subversion security model for not distinguishing
           between "you may know that PATH exists" and "you may see PATH's
           history, content and metadata".


          Issue Links



              • Assignee:
                cmpilato C. Michael Pilato
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: