How do you -identify- somebody (and hence their privileges) in a cross-platform way? Digital IDs/LDAP spring to mind, but I guess this is complex.
----- Original Message -----
From: "Bill Tutt" <rassilon@lyra.org>
To: "'C. Scott Ananian'" <cananian@lesser-magoo.lcs.mit.edu>
Cc: <dev@subversion.tigris.org>
Sent: Saturday, August 25, 2001 02:32
Subject: SVN and Authorization
>
>
> 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
>
>
---------------------------------------------------------------------
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