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

RE: Re: svn commit: rev 3010 - trunk/notes

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-08-22 09:49:26 CEST

> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
>
> On Thu, Aug 22, 2002 at 01:12:03AM -0500, jerenkrantz@tigris.org
wrote:
> > Author: jerenkrantz
> > Date: 2002-08-22 01:11:42 -0500 (Thu, 22 Aug 2002)
> > New Revision: 3010
> >
> > Modified:
> > trunk/notes/permissions
> > Log:
> > * notes/permissions: Expand scope to also include ACLs for SVN
itself.
> Add
> > notes on Win32 ACL structure. Expand to give ideas of how this
might
> > work.
>
> Yes, I'm conceptually expanding this to consider SVN enforcing ACLs
> in modifications applied to the repository.
>
> I think there is a strong correlation between client-side permissions
> and the server-side permissions. Therefore, we should at least
> examine how this might effect a hypothetical SVN server's security
> model.

I disagree. There is a very weak correlation. A SCM's security model
should be designed to handle SCM issues, and not to represent file
system security semantics.

> I tried to look to see if there was any documentation on a
> security model and didn't see any. (Truth be told, SVN can't really
> rely on httpd-2.0's ACL model as it just isn't expressive enough for
> a SCM system.)
>

That's right, a decent ACL model has been punted from 1.0. I'm not
thrilled about it, but I don't have time to help fix the problem either.
:(

> If a local copy has read-only permissions, then I believe the same
> should be true of that user's view of the repository.
>

I disagree partially here. Different SCM lock models typically make
files read only by default. I think Subversion will eventually have some
kind of lock model that will make this kind of thing happen.

> I think that the server-side and client-side enforcement of the
> security do not have to be implemented at the same time. Therefore,
> we could implement the client-side permissions and then subsequently
> add the server-side enforcement. (Or, vice versa.)
>

Assuming that the models should be that similar, this definitely is so.

> However, I think leaving a permissions model outside of the SCM
> system will be harmful if we don't address it and say that everyone
> must roll their own security model.
>

I agree. I'm not terribly happy with not having a decent security story
for Subversion's 1.0 release, but at least users can roll their own
security restrictions.

> I look at the craziness of the cvs_acls.pl script that the ASF
> uses and I think it'd be much cleaner if SVN addressed it head-on.
> The rise of such tools indicates that CVS is lacking here. -- justin
>

Yep. Unfortunately for Subversion 1.0, this same point will currently
apply.

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 22 12:01:21 2002

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.