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

Re: Milestone 2: authentication and authorization

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2000-12-15 04:04:24 CET

> I'm thinking of some table indexed by path, then revision number,
> with some nice, meaningful ordering to allow range searches...

I had this idea too. However, it means when you copy a file it
doesn't necessarily start out with the same permissions for others,
which could be a least-surprise security issue in some cases.

I've been wondering whether there is a qualitive difference between
the proper management of read permission versus write permission, and
whether our system should reflect that. If you want to restrict read
access to a resource, it is because the data itself is private. If
you want to restrict write access to a resource, it is because the
location is important; you don't particularly care if someone makes a
modified copy of the data at some other location. Also, you're much
more likely to want to make a repository world-readable by default
than to make it world-writable by default.

So, we could implement read access with properties (although it still
needs to be possible to retroactively restrict a particular
node-revision, which is a problem for our conception of properties)
and write access with a table, maybe. I'm completely unsure that we
want to make the split, but it's an interesting idea.
Received on Sat Oct 21 14:36:17 2006

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.