On Wed, Dec 13, 2000 at 07:08:01PM -0500, Jim Blandy wrote:
>...
> That said, there are two different approaches to handling this:
>
> - Apparently, you can specify access control lists in Apache
> configuration files. I've been too lazy to look up the details.
> Acknowledging my ignorance, though, I'm wary of this arrangement:
>
> - First, it seems like an unnecessarily loose coupling between the
> nodes and the controls you're putting on them. When someone
> renames a file, how does the ACL travel along with it? When
> someone deletes a file, shouldn't the ACL go away? Who guarantees
> this coordination? Are changes atomic and recoverable the way
> changes to the filesystem are?
Agreed. No. Yes. Nobody. Changes are to the httpd.conf, which implies a
restart, which is atomic (recoverable only if your prior httpd.conf is
recoverable).
> - What sorts of operations can an Apache-style ACL allow and forbid?
The ACLs that are builtin are per-HTTP-method (e.g. MKCOL, PUT, GET).
> In Subversion, it makes sense to distinguish between:
> 2) permission to change a directory's direct contents (add,
> delete, rename entries)
> 1) permission to change the directory's children (bubble-up)
> 0) no permission to change either the directory or any of its
> children
> Is that a distinction that fits nicely into Apache ACL's?
Normally, you'd just restrict the HTTP (DAV) methods which can alter the
content.
We can certainly write additional plugins that will do fine-grained ACL
checking however they like. The real question is: how are they specified in
the .conf file (or elsewhere), and what are the actual policies.
> In short, if the ACL's have behaviors dictated by Apache or DAV
> which show through the Subversion client to the user as surprising
> or counterintuitive semantics, I'll be unhappy. (I should wait
> until I know more before complaining, though.)
Go ahead and complain :-) ... I think that our ACLs will be FS-based. I
would characterize the standard Apache mechanisms as a high-level policy
(such as restricting changes to a whole repository), or as an administrative
second-level set of ACLs.
> However, it does avoid creating Yet Another Authorization System.
We have some design work needed to do a "smooth" integration. It won't be
hard at all to do the ACLs, but the tight integration will be a bit more.
Apache also has a read-only type ACL system. That has to be entirely
revamped if we are ever going to support persisting changes within the
*core* Apache (we certainly have persistent changes due to the FS). There
are also problems in Apache's ACL system when somebody changes it remotely:
consider that the change would then need to be reflected across all the
processes that Apache has spawned (presuming the ACLs are in memory rather
than on disk).
Essentially: Apache "core" has a rather poor ACL story at the moment. It is
extensible to meet our needs, but we will end up with something "different".
> Also, people have designed extensions to HTTP (is this part of DAV?)
> for tweaking permissions; it sounds like this arrangement would make
> it trivial for Subversion to work with those extensions.
Yes, there are DAV specs for remote management of ACLs. Please refer to:
http://www.webdav.org/acl/
> - We could store ACL's in the filesystem's non-historical node
> properties. This would let us choose whatever node/ACL coupling and
> operation set we find convenient and well-defined. From the Apache
> point of view, however, this could yield a fragmented and
> inconsistent authorization system.
>
> In the former system, it's possible that authorization would be
> implemented entirely in mod_dav_svn, with no help from the FS.
mod_dav_svn will always do some work. There are specific control points in
Apache for performing authorization. We would want to integrate with those,
rather than just waiting for the FS to return an error when we attempt to do
a "bad" operation.
If we rely entirely on Apache's model (which we shouldn't), then mod_dav_svn
wouldn't even need to do anything.
In terms of "fragmented": basically, the SVN ACLs system would be the only
one used within the SVN space. The httpd.conf wouldn't really even specify
anything, as it will all be stored and managed within the FS and
mod_dav_svn. Administrative types of (temporary) restrictions/ACLs would go
into the .conf, but we don't have any work to do for those.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006