Hello,
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
history?
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?
daniel
---------------------------------------------------------------------
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