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

Re: How much libsvn_repos wrap around the libsvn_fs

From: Michael Wood <mwood_at_its.uct.ac.za>
Date: 2003-01-03 11:12:28 CET

On Fri, Jan 03, 2003 at 12:37:07PM +0530, Nitin Shukla wrote:
> Indeed the access control is ultimately governed by OS file
> permissions. Is there a way of setting OS level file and folder
> permissions for every files and folder we check into the Subversion
> repository, say something similar to Unix style permission. Guess,

No, because the files are not stored separately in the repository as
files in a Unix filesystem. They are stored in a Berkeley DB database.
If you have read access to the Berkeley DB database files, you can get
access to their contents. There's no way to say that you can only
access certain parts of the Berkeley DB database.

> this would require an ACL system inherent to libsvn_fs. Probably, I
> am asking too much and trying to figure out something impossible.

Indeed :) Concentrate on ra_dav and ra_svn instead and ignore ra_local
as far as ACLs are concerned.

> ra_local really looks to be insecure by design. Does Subversion intend
> to eliminate this method of accessing repository in future version of
> subversion and probably use ra_svn even for local access.

Not as far as I know. As far as I am concerned, ra_local is really for
single user use (in which case ACLs don't make very much sense, except
for helping to minimise mistakes, like committing to a tag.)

If you want to use ra_local for multi-user access, then you have to
trust your users. If you want "proper" multi-user access, use ra_svn or
ra_dav, which can enforce the ACLs.

There's no reason to do away with ra_local, just because some people
need multi-user access with ACLs. There are still people who will just
want a small single-user repository for their own private stuff. Why
force them to use ra_svn or ra_dav when ra_local will do nicely?

Michael Wood <mwood@its.uct.ac.za>
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 3 11:13:36 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.