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 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.)
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 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.)
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 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 22 08:39:31 2002