You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sander Striker <st...@apache.org> on 2002/05/23 09:18:34 UTC
Authz, WAS: RE: libsvn_auth
> From: Glenn A. Thompson [mailto:gthompson@cdr.net]
> Sent: 23 May 2002 10:30
[...]
>> There are some issues with respect to doing fine grained access control
>> with Apache. Greg Stein and I tried to come up with an Apache configuration
>> that did fine grained access control, but we got bitten by the so
>> called '$svn' url.
>
> Not sure what you mean here, but what halted me was the idea that a given URL
> "name" can point to different nodes over time. wooaa. I planned on the ACLs
> being contained outside subversion at first. No No No. Once I thought about it,
> I freaked and stopped. It has to be in the Repos to work.
This was to see if we could get fine grained access control going without
implementing anything in subversion, so that if people really wanted it, they
could have it by doing it through Apache configuration.
And yes, you are right, several Locations can point to the same repository,
which would be a nightmare when it comes to access control. However, this
isn't really a problem since this is done in the same apache configuration
file where you took great care in doing access control. It would be stupid
to shoot yourself in the foot.
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.
Anyhow, not targetted at Glenn in particular, if you haven't read the ACL threads
in the archives, please try to locate and read them before following up. That
saves a lot of duplicated discussion.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Authz, WAS: RE: libsvn_auth
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
> Hey
> Anyhow, not targetted at Glenn in particular, if you haven't read the ACL threads
> in the archives, please try to locate and read them before following up. That
> saves a lot of duplicated discussion.
>
Sorry, thats the second thread I've hijacked this week.
I must do better research.
Back to my hole:-)
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 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
ACLs in Subversion (was: Re: Authz)
Posted by Greg Stein <gs...@lyra.org>.
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: Authz, WAS: RE: libsvn_auth
Posted by Branko Čibej <br...@xbc.nu>.
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.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org