On Friday, August 30, 2002, at 08:19 AM, Justin Erenkrantz wrote:
> On Fri, Aug 30, 2002 at 11:05:32AM +0200, brane@xbc.nu wrote:
>> Nonsense! Where did you get that idea? ACLs (and locks) will be a
>> feature of the
>> repository, and therefore exposed by all RA methods. We might copy ACL
>> _semantics_ from the DAV spec, but that's all.
>
> When I was discussing ACLs with Greg, he pointed out to me that
> it is useless to have ACLs on anything other than ra_dav.
>
> Since ra_local (and consequently ra_pipe) requires write access to
> the BDB files, if you don't like the ACLs, you can simply bring up
> python + BDB bindings and edit the repository. The same would go
> for a hypothetical ra_sql access layer.
>
> Therefore, if we were to go to the hassle of defining ACLs via
> ra_local, it merely provides a false sense of security. So, I
> believe my earlier statement is right - ra_dav will be the only
> RA implementation with ACL support. ACLs are a feature of the RA
> not the underlying repository itself. -- justin
ACLs provide not just security, but a way of enforcing policy. One of,
I'm sure, the many possible examples of this: Our policy is that
content editors cannot write to the java source code directories.
While I could have to write commit-hooks to check this specifically, it
seems like it would make more sense to use ACLs to define this
restriction. I'm not worried about my content editors getting python
and editing the database. I am worried about the content editors
accidentally committing accidental changes to the java code.
Your claim that ACLs don't provide any use here takes too narrow a view
of the use of ACLs.
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 30 18:12:00 2002