From: C. Scott Ananian [mailto:cananian@lesser-magoo.lcs.mit.edu]:
> On Sat, 25 Aug 2001, Sander Striker wrote:
> > The case where apache isn't involved. We need a way to let the
repos
> > handle if a user X is allowed Y on path Z. The berkeley argument
> > won't hold, since if we get around to implementing the sql backend,
> > writing to the repos isn't so easy as it is now with berkeley db.
> > This can be done through hooks. The read/write sentinels seems a
> > pretty efficient solution. Then again, discussion is always ok :)
> I read the berkeley db argument as, "The filesystem is responsible for
> authentication and enforcing access controls for local repositories".
> The initial file system implementation, built on Berkeley DB, seems to
> be a 'permissions-free' file system. As you point out, implementing
> the filesystem on top of a "real" DB would enforce whatever
> authentication/access control mechanisms the DB enforced. I'm still
> hoping for a plain-text unixy filesystem implementation at some point;
> this impl would extends unix authentication/etc to SVN.
Ick. You really don't want to use a unixy file system approach to
authorization issues.
Security models have gotten so much better since then.
Here's a possible security model for SVN:
There are the following access levels:
* Read: The level ViewSVN would need. Displays file histories, and
actual contents, but you can't actually commit any changes.
* Write: You can commit changes, and stuff.
* Admin: You can do anything. (user management, etc...)
An SVN ACL would contain the following info:
* Access level
* User/Group this Access Level applies to, can apply to everyone (except
admin).
* Hosts this access level is allowed for. (Standard IP wildcarding stuff
here)
* Path of the repository that this access applies to. E.g. a path of '/'
would mean apply to the whole repository. While a path of '/blah/blah2'
would apply to all subdirectories of blah2.
A DACL (deny ACL) would contain the exact same information, except it
would prevent the associated user/group from obtaining the requested
access level on a given path.
Decent security models allow resources to be accessed by more than one
group, and allow the use of DACLs to handle group overlap problem cases.
Unix filesystems don't even come close to allowing that kind of
flexibility.
Note: The above doesn't take any kind of consideration for the current
state of the SVN file system layer, it's just an idea. :)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006