You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2002/05/24 02:47:26 UTC

ACLs in Subversion (was: Re: Authz)

On Thu, May 23, 2002 at 10:17:08PM +0200, Branko Äibej wrote:
> Sander Striker wrote:
> >As for "it has to be in the repos to work", yes, true.  I think we came up
> >with implementing it using svn:acl properties.  This is what I would like to
> >see as a priority item _post_ 1.0.
>
> Sadly, that won't work. You want to be able to change the ACL on an old 
> version, so props aren't appropriate.

Right.

ACLs are a complete and total bitch when you have a versioning repository
with copy-by-reference.

* use ACLs that are path-based?
  - pro: works great for "going back in time" to protect content
  - con: fails once you make a copy

* use ACLs that are attached to an item?
  - pro: survives copies
  - con: back up one revision to avoid the ACL


At some point, we'll need to find a solution. But for now, I'm going to keep
my head from exploding and ignore the problem.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ACLs in Subversion (was: Re: Authz)

Posted by Alan Langford <ja...@ambitonline.com>.
At 2002/05/23 23:54 -0400, Greg Hudson wrote:
>If we do want to record a history of ACL changes, then a possible
>solution is to have an acl file somewhere in the Subversion file space
>(similar in principle to the Apache access control config file), and
>then when you make a copy, the filesystem magically edits the acl file
>so that the acl on the new node matches the acl on the old node.  That's
>kind of weird, though, and calls into question how things work when you
>want to make a copy and edit the acl file at the same time.

1) Don't version the ACLs.
2) Keep ACLs in a separate "versioning space". Aren't changes to the ACLs 
orthogonal to changes to the rest of the file base?



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ACLs in Subversion (was: Re: Authz)

Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2002-05-23 at 23:46, Glenn A. Thompson wrote:
> OK thats what I hoped you meant.  Read can be exposed. Not write.  But it was
> readable at 9 before anyway.  I think this is reasonable and consistant.

Consistent, yes.  Reasonable, no.  You need to be able to retcon ACL's
when:

  * You discover that you forgot to set a restrictive ACL on some
proprietary source you brought online last week.

  * You hire someone new and need to give them read access to the change
history of the proprietary source code.

The latter problem can be solved if we implement a group system inside
Subversion (an ACL would point to a group, and the group could be
changed without changing the ACL itself), but man, that's a lot of hair.

One question is how important it is to record a history of ACL changes.
If it's not, we can simply provide an interface for changing properties
(or some concept which is "just like properties") on old revisions of a
node and have done with it.

If we do want to record a history of ACL changes, then a possible
solution is to have an acl file somewhere in the Subversion file space
(similar in principle to the Apache access control config file), and
then when you make a copy, the filesystem magically edits the acl file
so that the acl on the new node matches the acl on the old node.  That's
kind of weird, though, and calls into question how things work when you
want to make a copy and edit the acl file at the same time.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ACLs in Subversion (was: Re: Authz)

Posted by "Glenn A. Thompson" <gt...@cdr.net>.
>

Hey

>
> 1. revision 9 has no ACLs.
> 2. I add an ACL to BAR and commit. I now have rev 10.
> 3. Random Joe comes along and can't read BAR
> 4. he falls back to rev 9 and reads BAR since it has no ACL.

OK thats what I hoped you meant.  Read can be exposed. Not write.  But it was
readable at 9 before anyway.  I think this is reasonable and consistant.  The
default mechanism being kicked around could come in handy for this.  Default the ACL
on the parent dir so that the first version always gets an ACL.

gat


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ACLs in Subversion (was: Re: Authz)

Posted by Greg Stein <gs...@lyra.org>.
On Thu, May 23, 2002 at 11:15:02PM -0400, Glenn A. Thompson wrote:
>...
> > * use ACLs that are attached to an item?
> >   - pro: survives copies
> >   - con: back up one revision to avoid the ACL
>...
> I don't see how backing up avoids the ACL in any significant way?  But this is
> tough to get the ol brain around.

1. revision 9 has no ACLs.
2. I add an ACL to BAR and commit. I now have rev 10.
3. Random Joe comes along and can't read BAR
4. he falls back to rev 9 and reads BAR since it has no ACL.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ACLs in Subversion (was: Re: Authz)

Posted by "Glenn A. Thompson" <gt...@cdr.net>.
> Right.
>
> ACLs are a complete and total bitch when you have a versioning repository
> with copy-by-reference.
>
> * use ACLs that are path-based?
>   - pro: works great for "going back in time" to protect content
>   - con: fails once you make a copy
>
> * use ACLs that are attached to an item?
>   - pro: survives copies
>   - con: back up one revision to avoid the ACL
>
> At some point, we'll need to find a solution. But for now, I'm going to keep
> my head from exploding and ignore the problem.
>

Well can't we make it explode just a little bit? :-)

I don't see how backing up avoids the ACL in any significant way?  But this is
tough to get the ol brain around.

gat


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org