You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2004/07/06 20:12:14 UTC
Re: herding 1.1 issues into the corral
Ben Collins-Sussman <su...@collab.net> writes:
> ### 1949 mod_authz_svn COPY bug: Is this a 1.1 showstopper or not?
> Should we implement pseudo-O(N) copies, or just doc around it?
Not a showstopper, IMHO. We've had the bug forever; we should doc
around it for 1.1, not delay 1.1 when we don't even know the fix yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On fixing the authz problem (was Re: herding 1.1 issues into
the corral)
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey,
Michael W Thelen wrote:
>* Greg Hudson <gh...@MIT.EDU> [2004-07-07 06:46]:
>
>
>>On Wed, 2004-07-07 at 03:41, Michael W Thelen wrote:
>>
>>
>>>I'm
>>>thinking that a new svn_config function is needed to provide the full
>>>list of config sections (or call a callback for each one).
>>>
>>>
>>Correct; to implement Ben's solution, we need an svn_config_enumerate
>>analog for sections rather than variables within a section. For
>>consistency, a callback interface makes sense, although in a vacuum I'd
>>suggest returning an array as you first suggest, since C callbacks are
>>awkward.
>>
>>
>
>Thanks, that should be the last piece in the puzzle for implementing
>Ben's solution. I'll do that tonight (the callback for consistency) and
>if all goes well, I should have a patch for review by tomorrow.
>
Cool!
I haven't been keeping up with Subversion at all. But, it's weird, for
some unknown reason I clicked on this thread.
on page 13 of http://www.cdrguys.com/subversion/pluggable3.pdf (FS
Configuration usage) I mention this change along with one other small
change. The other thing I wanted was a "new" method to create an empty
svn_config_t programmatically. It may be there now I wouldn't know. I
had patches for them a long long long time ago. Anyway, the new method
would be really nice to have if it's not already there.
Thanks,
gat
Re: On fixing the authz problem (was Re: herding 1.1 issues into the corral)
Posted by Michael W Thelen <th...@cs.utah.edu>.
* Greg Hudson <gh...@MIT.EDU> [2004-07-07 06:46]:
> On Wed, 2004-07-07 at 03:41, Michael W Thelen wrote:
> > I'm
> > thinking that a new svn_config function is needed to provide the full
> > list of config sections (or call a callback for each one).
>
> Correct; to implement Ben's solution, we need an svn_config_enumerate
> analog for sections rather than variables within a section. For
> consistency, a callback interface makes sense, although in a vacuum I'd
> suggest returning an array as you first suggest, since C callbacks are
> awkward.
Thanks, that should be the last piece in the puzzle for implementing
Ben's solution. I'll do that tonight (the callback for consistency) and
if all goes well, I should have a patch for review by tomorrow.
-- Mike
--
Michael W. Thelen
We who cut mere stones must always be envisioning cathedrals.
-- Quarry worker's creed
On fixing the authz problem (was Re: herding 1.1 issues into the
corral)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-07-07 at 03:41, Michael W Thelen wrote:
> I'm
> thinking that a new svn_config function is needed to provide the full
> list of config sections (or call a callback for each one).
Correct; to implement Ben's solution, we need an svn_config_enumerate
analog for sections rather than variables within a section. For
consistency, a callback interface makes sense, although in a vacuum I'd
suggest returning an array as you first suggest, since C callbacks are
awkward.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: herding 1.1 issues into the corral
Posted by Michael W Thelen <th...@cs.utah.edu>.
* Michael W Thelen <th...@cs.utah.edu> [2004-07-06 15:53]:
> * Ben Collins-Sussman <su...@collab.net> [2004-07-06 15:47]:
> > Of course we know the fix. mod_authz_svn reads the entire authz INI
> > file into memory for every request. All we need to do is
> >
> > 1. write a function in mod_authz_svn.c which verifies whether a user
> > has read access to an entire tree. That's just a matter of looping over
> > all paths in the authz file which prefix-match the tree.
> >
> > 2. invoke this function on the source path of any COPY request.
> >
> > Pretty easy stuff. Personally, I think we should do it. COPY requests
> > (svn cp URL1 URL2) are relatively rare, and we can document the fact
> > that mod_authz_svn places a bit of a damper on O(1) copies.
>
> Hey, that sounds like something even I could do :) Anyone mind if I
> give it a shot tonight and post again tomorrow if it looks like it's
> going to be beyond me?
So... I'm feeling pretty good about being able to fix this, except for
one thing. How do you get the list of all paths in the authz file in
order to loop over them?
The current code checks all paths from the requested path upward, by
chopping basenames one at a time and calling svn_config_enumerate for
each parent directory. That doesn't require knowing all the sections in
the authz file, because you can examine the requested path and deduce
all its parent directories. But going downward, we need a list of all
sections in the authz file, and I can't figure out how to get them. At
the point I need them in mod_authz_svn.c, I have a svn_config_t*, but no
direct access to what's in there since I haven't included config_impl.h
(which I assume is a bad idea since it hasn't already been done). I'm
thinking that a new svn_config function is needed to provide the full
list of config sections (or call a callback for each one). Any other
suggestions?
-- Mike
--
Michael W. Thelen
How many a man has dated a new era in his life from the reading of a book.
-- Henry David Thoreau
Re: herding 1.1 issues into the corral
Posted by Michael W Thelen <th...@cs.utah.edu>.
* Ben Collins-Sussman <su...@collab.net> [2004-07-06 15:47]:
> Of course we know the fix. mod_authz_svn reads the entire authz INI
> file into memory for every request. All we need to do is
>
> 1. write a function in mod_authz_svn.c which verifies whether a user
> has read access to an entire tree. That's just a matter of looping over
> all paths in the authz file which prefix-match the tree.
>
> 2. invoke this function on the source path of any COPY request.
>
> Pretty easy stuff. Personally, I think we should do it. COPY requests
> (svn cp URL1 URL2) are relatively rare, and we can document the fact
> that mod_authz_svn places a bit of a damper on O(1) copies.
Hey, that sounds like something even I could do :) Anyone mind if I
give it a shot tonight and post again tomorrow if it looks like it's
going to be beyond me?
-- Mike
--
Michael W. Thelen
If you don't know where you are going, you will probably end up somewhere
else. -- Laurence J. Peter
Re: herding 1.1 issues into the corral
Posted by Ben Collins-Sussman <su...@collab.net>.
kfogel@collab.net wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
>>### 1949 mod_authz_svn COPY bug: Is this a 1.1 showstopper or not?
>> Should we implement pseudo-O(N) copies, or just doc around it?
>
>
> Not a showstopper, IMHO. We've had the bug forever; we should doc
> around it for 1.1, not delay 1.1 when we don't even know the fix yet.
Of course we know the fix. mod_authz_svn reads the entire authz INI
file into memory for every request. All we need to do is
1. write a function in mod_authz_svn.c which verifies whether a user
has read access to an entire tree. That's just a matter of looping over
all paths in the authz file which prefix-match the tree.
2. invoke this function on the source path of any COPY request.
Pretty easy stuff. Personally, I think we should do it. COPY requests
(svn cp URL1 URL2) are relatively rare, and we can document the fact
that mod_authz_svn places a bit of a damper on O(1) copies.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org