[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Repository ACL's

From: Daniel Patterson <danpat_at_adaptiveinternational.com>
Date: 2003-04-16 08:15:53 CEST


  Subversion has wowed and impressed may people here, to the point
  that there is much talk of rolling it out as a general purpose
  file store across our company. Putting project code, docs,
  traditionally unversioned (and therefore broken) files all together
  in one place appeals greatly.

  However, there is one major stumbling block: access control.

  We currently expose parts of our filesystems to customers who work
  with us on projects (via DAV from their offices usually), and we have
  some custom apache modules written to use the native POSIX permissions
  running directly from the filesystem (trickery with Apache seteuid()
  makes this work ok, apart from the potential security holes). We also
  like to hide files/directories that users don't have read access to
  (some legal requirements, customers can't see each other, etc) with
  some modifications to mod_dav (yes, it hurts performance, but that's
  no biggie).

  Ideally, I'd like to see something similar to POSIX ACL's in the
  svn filesystem, however, I forsee the following issues:

    1) What do permissions on files mean throughout the repository

       From our business point of view, if someone has access revoked
       from a resource, this means *all* versions of the resource,
       not just HEAD and into the future.
       This doesn't fit with the model of "the history is the history,
       you shan't change it" that is the *good* think about a versioned
       filesystem. Unfortunately, our business users can't seem
       to recognise when their requirements are orthoganal.

    2) A good place to store ACL data seems to be in a file property.
       However, it seems a bit unclean for libsvn_fs, examining file
       metadata to determine access seems to be a bit of a mis-match.
       Does the permission data belong below the property level
       (and inside the db itself)? Perhaps the ACL data should
       be an unversioned property on the transaction.....

    3) What does it mean when you checkout a WC with ACL's all over
       the place? Ideally, you'd get the ACL's set on disk the same
       as they are in the repository (assuming a POSIX-style ACL
       implementation and a WC filesystem that supports it). My
       head starts to spin here. Perhaps ignore the ACL's in the WC
       and the client treats them like any other property (this would
       mean zero re-work in the client....)

  Ideally, we want to be able to simply slot SVN in place of the
  existing DAV service (using autoversioning to begin with). This
  means we want to simulate the behaviour we've currently got.

  I had a brief look back through the archives, and it seems that
  permissions seem to have been "put off". I may or may not get some
  time to implement something along these lines, depending on the
  time it might take to implement.

  Has anyone put any thought into this kind of feature?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 16 08:16:48 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.