You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2011/01/27 19:44:35 UTC
RE: svn commit: r1064093 -/subversion/trunk/subversion/libsvn_repos/authz.c
>> It might be a rare situation,
>> but *if* folks have come to depend on the case-sensitivity of these checks,
>> they need to prepare for the fallout of this loosening of the policy.
>>
>Sorry for not thinking about this earlier, but:
>Why was the fix to make all checks case-INsensitive, as opposed to
>making all checks case-sensitive?
We use svn_config_read to parse the authz which always stores the section names in *lower* case in its internal hash table.
See subversion/libsvn_subr/config.c:make_hash_key().
We need to rev svn_config_read to accept bool case_sensitive_section_parser. Then we can change the behaviour to always case-sensitive approach as against today's case-insensitive approach.
With regards
Kamesh Jayachandran
RE: svn commit: r1064093-/subversion/trunk/subversion/libsvn_repos/authz.c
Posted by Kamesh Jayachandran <ka...@collab.net>.
>-----Original Message-----
>From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
>Sent: Fri 1/28/2011 12:16 AM
>To: Kamesh Jayachandran; Arwin Arni Nandagopal
>Cc: dev@subversion.apache.org
>Subject: Re: svn commit: r1064093-/subversion/trunk/subversion/libsvn_repos/authz.c
>Kamesh Jayachandran wrote on Fri, Jan 28, 2011 at 00:14:35 +0530:
>>
>> >> It might be a rare situation,
>> >> but *if* folks have come to depend on the case-sensitivity of these checks,
>> >> they need to prepare for the fallout of this loosening of the policy.
>> >>
>>
>> >Sorry for not thinking about this earlier, but:
>> >Why was the fix to make all checks case-INsensitive, as opposed to
>> >making all checks case-sensitive?
>>
>> We use svn_config_read to parse the authz which always stores the section names in *lower* case in its internal hash table.
>>
>> See subversion/libsvn_subr/config.c:make_hash_key().
>>
>> We need to rev svn_config_read to accept bool case_sensitive_section_parser. Then we can change the behaviour to always case-sensitive approach as against today's case-insensitive approach.
>>
>Thanks for the reminder.
>Do you think it's a good idea?
>Personally I'm +0.5, since IMO we should be treating pathnames
>case-insensitively.
Same case with me.
With regards
Kamesh Jayachandran
Re: svn commit: r1064093 -/subversion/trunk/subversion/libsvn_repos/authz.c
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Jan 27, 2011 at 11:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
> If we have have the option of moving towards case-sensitivity -- that is, a
> *more*-precise authz policy -- that seems like a good thing. I'd even be in
> favor of making this behavior optional (like the force_username_case option
> we already have).
Given that we do wonky things on the client side when cases are mixed
in the same path, I think it'd be very weird to make this behavior
optional. It's so highly unlikely that anyone is going to want apply
rules to "AuthZ" but not to "authz" - especially given that it
wouldn't have worked *at all* before anyway.
My $.02. -- justin
Re: svn commit: r1064093
-/subversion/trunk/subversion/libsvn_repos/authz.c
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Thu, Jan 27, 2011 at 15:33:17 -0500:
> On 01/27/2011 02:18 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Thu, Jan 27, 2011 at 14:14:11 -0500:
> >> If we have have the option of moving towards case-sensitivity -- that is, a
> >> *more*-precise authz policy -- that seems like a good thing. I'd even be in
> >> favor of making this behavior optional (like the force_username_case option
> >> we already have).
> >>
> >
> > Could you clarify? What modes are you suggesting to support, and which
> > would be the default one?
>
> Well, I was thinking about "authz-section-case-sensitive = true|false" in
> svnserve.conf, and "SVNAuthzSectionCaseSensitive on|off" for the DAV
> modules. Enabling this gives us case sensitivity in our treatment of those
> authz section names (which include repository names and paths); disabling
> makes it case-insensitive.
>
> But I confess that I'm only considering this as a way to avoid breaking
> existing authz files that are exploiting the case-insensitivity we have
> today. If we all agree that case-*sensitivity* (or case-insensitivity) is
> The Way To Go, and that the realistic user effect of consistification here
> is negligible, then toss the "make it optional" suggestion altogether.
>
I've already expressed my opinion (+1 to casefulness), so I'll let
others chime in now.
In any case, is anyone interested in writing a patch in this direction
(once we agree what the direction is)?
/me looking at Arwin
> > Also: where is force_username_case documented? The default
> > svnserve.conf doesn't mention it.
>
> Really?
No, sorry.
(I used my new-test-repository script instead of plain 'svnadmin create'.)
Re: svn commit: r1064093 -/subversion/trunk/subversion/libsvn_repos/authz.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/27/2011 02:18 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Thu, Jan 27, 2011 at 14:14:11 -0500:
>> On 01/27/2011 01:46 PM, Daniel Shahaf wrote:
>>> Personally I'm +0.5, since IMO we should be treating pathnames
>>> case-insensitively.
>>
>> (Did you mean "case-sensitively"?)
>>
>
> Yes.
>
>> If we have have the option of moving towards case-sensitivity -- that is, a
>> *more*-precise authz policy -- that seems like a good thing. I'd even be in
>> favor of making this behavior optional (like the force_username_case option
>> we already have).
>>
>
> Could you clarify? What modes are you suggesting to support, and which
> would be the default one?
Well, I was thinking about "authz-section-case-sensitive = true|false" in
svnserve.conf, and "SVNAuthzSectionCaseSensitive on|off" for the DAV
modules. Enabling this gives us case sensitivity in our treatment of those
authz section names (which include repository names and paths); disabling
makes it case-insensitive.
But I confess that I'm only considering this as a way to avoid breaking
existing authz files that are exploiting the case-insensitivity we have
today. If we all agree that case-*sensitivity* (or case-insensitivity) is
The Way To Go, and that the realistic user effect of consistification here
is negligible, then toss the "make it optional" suggestion altogether.
> Also: where is force_username_case documented? The default
> svnserve.conf doesn't mention it.
Really? I see it in my default svnserve.conf under the [general] section.
Though, it's "force-username-case" (hyphens, not underscores; sorry).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r1064093
-/subversion/trunk/subversion/libsvn_repos/authz.c
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Thu, Jan 27, 2011 at 14:14:11 -0500:
> On 01/27/2011 01:46 PM, Daniel Shahaf wrote:
> > Personally I'm +0.5, since IMO we should be treating pathnames
> > case-insensitively.
>
> (Did you mean "case-sensitively"?)
>
Yes.
> If we have have the option of moving towards case-sensitivity -- that is, a
> *more*-precise authz policy -- that seems like a good thing. I'd even be in
> favor of making this behavior optional (like the force_username_case option
> we already have).
>
Could you clarify? What modes are you suggesting to support, and which
would be the default one?
Also: where is force_username_case documented? The default
svnserve.conf doesn't mention it.
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
Re: svn commit: r1064093 -/subversion/trunk/subversion/libsvn_repos/authz.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/27/2011 01:46 PM, Daniel Shahaf wrote:
> Personally I'm +0.5, since IMO we should be treating pathnames
> case-insensitively.
(Did you mean "case-sensitively"?)
If we have have the option of moving towards case-sensitivity -- that is, a
*more*-precise authz policy -- that seems like a good thing. I'd even be in
favor of making this behavior optional (like the force_username_case option
we already have).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r1064093
-/subversion/trunk/subversion/libsvn_repos/authz.c
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Kamesh Jayachandran wrote on Fri, Jan 28, 2011 at 00:14:35 +0530:
>
> >> It might be a rare situation,
> >> but *if* folks have come to depend on the case-sensitivity of these checks,
> >> they need to prepare for the fallout of this loosening of the policy.
> >>
>
> >Sorry for not thinking about this earlier, but:
> >Why was the fix to make all checks case-INsensitive, as opposed to
> >making all checks case-sensitive?
>
> We use svn_config_read to parse the authz which always stores the section names in *lower* case in its internal hash table.
>
> See subversion/libsvn_subr/config.c:make_hash_key().
>
> We need to rev svn_config_read to accept bool case_sensitive_section_parser. Then we can change the behaviour to always case-sensitive approach as against today's case-insensitive approach.
>
Thanks for the reminder.
Do you think it's a good idea?
Personally I'm +0.5, since IMO we should be treating pathnames
case-insensitively.
Daniel
> With regards
> Kamesh Jayachandran