Re: Repository ACL's

Daniel Patterson wrote:

>On Thu, 2003-04-17 at 07:00, Branko Čibej wrote:
>
>
>>Well, it gives me a headache because I /have/ put quite a bit of thought
>>into it. ::-)
>>Didn't get any coherent results out, though...
>>
>>
>
>Do you have anything written down?
>

Nope.

> I'd like to establish whether
>it's even possible or not (I'm getting a gut feeling that access control
>and versioning are mutually exclusive for some reason....)
>

They aren't mutually exclusive. It's just a lot harder to get a coherent
definition of ACL semantics in the presence of versioning.

>An interesting point in the webdav ACL notes:
>
>* Given Subversion does not know about users,
>

This bit isn't exactly true, of course. The subversion FS *currently*
doesn't know about users, but it would, if ACLs were part of it. And
Subversion does know about users. Authentication is another matter,
specific to the RA method.

> what sorts of ACLs could
> be placed on other non-DAV access to the repository (say ra_local)?
>Justin: Greg hints that ra_local doesn't use ACLs as it would be
> possible to just bypass SVN and edit the BDB backend directly.
>

Of course that's possible. However, if ACLs aren't part of the SVN FS,
two things happen:

    * Administrators can't use ra_local to modify ACLs
    * Other access methods (e.g., ra_svn) don't honour the ACLs, either.

Both seem like a bad idea to me.

> ACLs are therefore only desired for ra_dav access.
>
>This kind of hints to me that access control won't work at all over
>ra_local without some other kind of backend, so perhaps the webdav
>approach is a correct one (or at least, points to the layer where
>access control belongs)?
>
>

As I said, access control belongs in the FS, not in a server layer. The
server layer must take care of authentication, of course. What we have
to come up with is an ACL design that can be *mapped* to/from the WebDAV
ACL semantics.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org