You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ivan Zhakov <iv...@visualsvn.com> on 2015/01/16 20:18:17 UTC
Logging of subrequest authorization checks in mod_dav_svn/mod_authz_svn
When doing operations like 'svn log' or 'svn ls' Subversion hides
paths that are unreadable for user.
I.e. if repository contains the following directories:
/public
/private
And authorization file looks like this:
[/]
* = r
[/private]
* =
Then 'svn ls REPOROOT' command will return only /public directory. The
'svn log' command does the same. So from the user prespective the
/private directory does not exist.
The problem is that Subversion 1.8.x always logs an error for *every*
access check for unreadable path.This result in thousands of error log
messages for one request, even if user didn't tried to access
unreadable path directly. In trunk (r1562417) behavior were slightly
changed and all "access denied" messages now logged with 'warning'
level instead of 'error'.
But I'm not sure that current behavior is the best. I'm thinking to
implement the following logic in mod_authz_svn: use different log
level whether access denied for subrequest or for primary request (the
URL user actually tried to access).
Does it make sense?
The other open question is which error level use for these 'soft'
access denied messages:
a) info (Like we do for access granted messages)
b) warning
I would like to resolve this problem before the 1.9 branch. The patch
should be simple, but I need help from the community to make this
decision.
Thoughts?
--
Ivan Zhakov
Re: Logging of subrequest authorization checks in
mod_dav_svn/mod_authz_svn
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Tue, Jan 20, 2015 at 13:13:05 +0100:
> On 20 Jan 2015 12:54, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
>
> > On 20 January 2015 at 14:15, Branko Čibej <br...@wandisco.com> wrote:
> > > On 19.01.2015 18:10, Ivan Zhakov wrote:
> > >> I've implemented proposed behavior in r1653032.
> > >>
> > >> On 18 January 2015 at 06:48, Daniel Shahaf <d....@daniel.shahaf.name>
> > wrote:
> > >>> It would be nice if the the logged message should be different in that
> > >>> case, too. That is: there should be some indication, besides the
> > >>> different log level, that the subrequest-generated log event is
> > >>> "normal".
> > >>>
> > >>> That is, we don't want this:
> > >>>
> > >>> [debug] Access denied: /private
> > >>> [error] Access denied: /private
> > >>>
> > >>> But this:
> > >>>
> > >>> [debug] Hiding directory '/private' (Access denied)
> > >>> [error] Access denied: /private
> > >>>
> > >>> (Or some other log level instead of "debug" — I haven't thought about
> > >>> what log level would be appropriate.)
> > >> I agree that different log message would be nice to have, but there is
> > >> an issue: in mod_authz_svn we're not 100% sure that path will be
> > >> hidden. mod_authz_svn just answer the question whether access allowed
> > >> or not, but it doesn't know how this information will be used latter
> > >> at mod_dav_svn layer. May be different wording may fix this issue
> > >> though.
> > >
> > > I'm confused: when/why would mod_dav_svn ignore the result of an authz
> > > check?
> > >
> > I meant that hiding unreadable path is not only possible behavior for
> > mod_dav_svn. For example it may error out if it got unreadable path.
> > For example get-locks-report: attempt to get lock for unreadable path
> > will result requested failure (subversion\mod_dav_svn\lock.c:470). IMO
> > logging "Hiding path" will be confusing for user.
> >
> Right, understood. So 'hiding path" is not wording that mod_authz_svn can
> use, but we can come up with some authz-specific wording that's different
> from the current "access denied," right?
How about:
is_subreq_bypass is true:
"Access denied (subrequest=0)"
is_subreq_bypass is false:
"Access denied (subrequest=1)"
That's more or less the least imaginative thing possible, but I think
it's better than having to ask people whether their "Access denied"
error message was at [info] or at [error].
WDYT?
Re: Logging of subrequest authorization checks in mod_dav_svn/mod_authz_svn
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 20 January 2015 at 15:13, Branko Čibej <br...@wandisco.com> wrote:
> Right, understood. So 'hiding path" is not wording that mod_authz_svn can
> use, but we can come up with some authz-specific wording that's different
> from the current "access denied," right?
>
Yes, right.
--
Ivan Zhakov
Re: Logging of subrequest authorization checks in mod_dav_svn/mod_authz_svn
Posted by Branko Čibej <br...@wandisco.com>.
Right, understood. So 'hiding path" is not wording that mod_authz_svn can
use, but we can come up with some authz-specific wording that's different
from the current "access denied," right?
On 20 Jan 2015 12:54, "Ivan Zhakov" <iv...@visualsvn.com> wrote:
> On 20 January 2015 at 14:15, Branko Čibej <br...@wandisco.com> wrote:
> > On 19.01.2015 18:10, Ivan Zhakov wrote:
> >> I've implemented proposed behavior in r1653032.
> >>
> >> On 18 January 2015 at 06:48, Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
> >>> It would be nice if the the logged message should be different in that
> >>> case, too. That is: there should be some indication, besides the
> >>> different log level, that the subrequest-generated log event is
> >>> "normal".
> >>>
> >>> That is, we don't want this:
> >>>
> >>> [debug] Access denied: /private
> >>> [error] Access denied: /private
> >>>
> >>> But this:
> >>>
> >>> [debug] Hiding directory '/private' (Access denied)
> >>> [error] Access denied: /private
> >>>
> >>> (Or some other log level instead of "debug" — I haven't thought about
> >>> what log level would be appropriate.)
> >> I agree that different log message would be nice to have, but there is
> >> an issue: in mod_authz_svn we're not 100% sure that path will be
> >> hidden. mod_authz_svn just answer the question whether access allowed
> >> or not, but it doesn't know how this information will be used latter
> >> at mod_dav_svn layer. May be different wording may fix this issue
> >> though.
> >
> > I'm confused: when/why would mod_dav_svn ignore the result of an authz
> > check?
> >
> I meant that hiding unreadable path is not only possible behavior for
> mod_dav_svn. For example it may error out if it got unreadable path.
> For example get-locks-report: attempt to get lock for unreadable path
> will result requested failure (subversion\mod_dav_svn\lock.c:470). IMO
> logging "Hiding path" will be confusing for user.
>
>
> --
> Ivan Zhakov
> CTO | VisualSVN | http://www.visualsvn.com
>
Re: Logging of subrequest authorization checks in mod_dav_svn/mod_authz_svn
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 20 January 2015 at 14:15, Branko Čibej <br...@wandisco.com> wrote:
> On 19.01.2015 18:10, Ivan Zhakov wrote:
>> I've implemented proposed behavior in r1653032.
>>
>> On 18 January 2015 at 06:48, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>> It would be nice if the the logged message should be different in that
>>> case, too. That is: there should be some indication, besides the
>>> different log level, that the subrequest-generated log event is
>>> "normal".
>>>
>>> That is, we don't want this:
>>>
>>> [debug] Access denied: /private
>>> [error] Access denied: /private
>>>
>>> But this:
>>>
>>> [debug] Hiding directory '/private' (Access denied)
>>> [error] Access denied: /private
>>>
>>> (Or some other log level instead of "debug" — I haven't thought about
>>> what log level would be appropriate.)
>> I agree that different log message would be nice to have, but there is
>> an issue: in mod_authz_svn we're not 100% sure that path will be
>> hidden. mod_authz_svn just answer the question whether access allowed
>> or not, but it doesn't know how this information will be used latter
>> at mod_dav_svn layer. May be different wording may fix this issue
>> though.
>
> I'm confused: when/why would mod_dav_svn ignore the result of an authz
> check?
>
I meant that hiding unreadable path is not only possible behavior for
mod_dav_svn. For example it may error out if it got unreadable path.
For example get-locks-report: attempt to get lock for unreadable path
will result requested failure (subversion\mod_dav_svn\lock.c:470). IMO
logging "Hiding path" will be confusing for user.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: Logging of subrequest authorization checks in mod_dav_svn/mod_authz_svn
Posted by Branko Čibej <br...@wandisco.com>.
On 19.01.2015 18:10, Ivan Zhakov wrote:
> I've implemented proposed behavior in r1653032.
>
> On 18 January 2015 at 06:48, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> It would be nice if the the logged message should be different in that
>> case, too. That is: there should be some indication, besides the
>> different log level, that the subrequest-generated log event is
>> "normal".
>>
>> That is, we don't want this:
>>
>> [debug] Access denied: /private
>> [error] Access denied: /private
>>
>> But this:
>>
>> [debug] Hiding directory '/private' (Access denied)
>> [error] Access denied: /private
>>
>> (Or some other log level instead of "debug" — I haven't thought about
>> what log level would be appropriate.)
> I agree that different log message would be nice to have, but there is
> an issue: in mod_authz_svn we're not 100% sure that path will be
> hidden. mod_authz_svn just answer the question whether access allowed
> or not, but it doesn't know how this information will be used latter
> at mod_dav_svn layer. May be different wording may fix this issue
> though.
I'm confused: when/why would mod_dav_svn ignore the result of an authz
check?
-- Brane
Re: Logging of subrequest authorization checks in mod_dav_svn/mod_authz_svn
Posted by Ivan Zhakov <iv...@visualsvn.com>.
I've implemented proposed behavior in r1653032.
On 16 January 2015 at 22:52, C. Michael Pilato <cm...@collab.net> wrote:
[...]
>
> As for log levels, is there any reason to log the implicit read attempts
> at a level higher than "debug"? I have no opinion about the log level
> for the explicit ones.
>
Some audit tools may parse logs to collect information of all path
accessed by user. So I've decided to use INFO level for such implicit
attempts.
On 17 January 2015 at 00:45, Branko Čibej <br...@wandisco.com> wrote:
>> I have no opinion about the log level for the explicit ones.
>
> I believe a request for /private will return a 404 error, same as a
> request for a non-existent path. And IIRC these are normally logged at
> error level.
Agree, that what I implemented in r1653032.
On 18 January 2015 at 06:48, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> It would be nice if the the logged message should be different in that
> case, too. That is: there should be some indication, besides the
> different log level, that the subrequest-generated log event is
> "normal".
>
> That is, we don't want this:
>
> [debug] Access denied: /private
> [error] Access denied: /private
>
> But this:
>
> [debug] Hiding directory '/private' (Access denied)
> [error] Access denied: /private
>
> (Or some other log level instead of "debug" — I haven't thought about
> what log level would be appropriate.)
I agree that different log message would be nice to have, but there is
an issue: in mod_authz_svn we're not 100% sure that path will be
hidden. mod_authz_svn just answer the question whether access allowed
or not, but it doesn't know how this information will be used latter
at mod_dav_svn layer. May be different wording may fix this issue
though.
--
Ivan Zhakov
Re: Logging of subrequest authorization checks in mod_dav_svn/mod_authz_svn
Posted by Branko Čibej <br...@wandisco.com>.
On 16.01.2015 20:52, C. Michael Pilato wrote:
> On 01/16/2015 02:18 PM, Ivan Zhakov wrote:
>> But I'm not sure that current behavior is the best. I'm thinking to
>> implement the following logic in mod_authz_svn: use different log
>> level whether access denied for subrequest or for primary request (the
>> URL user actually tried to access).
>>
>> Does it make sense?
>>
>> The other open question is which error level use for these 'soft'
>> access denied messages:
>> a) info (Like we do for access granted messages)
>> b) warning
> It makes sense to me to log explicit attempts to hit an unreadable
> resource differently than the somewhat unavoidable implicit attempts.
>
> As for log levels, is there any reason to log the implicit read attempts
> at a level higher than "debug"?
Sounds good; I understand that there will be no equivalent entry in the
access log for these sub-requests, so they're not really interesting to
the admin in normal operations.
> I have no opinion about the log level for the explicit ones.
I believe a request for /private will return a 404 error, same as a
request for a non-existent path. And IIRC these are normally logged at
error level.
-- Brane
Re: Logging of subrequest authorization checks in
mod_dav_svn/mod_authz_svn
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ben Reser wrote on Fri, Jan 16, 2015 at 14:09:45 -0800:
> On 1/16/15 11:52 AM, C. Michael Pilato wrote:
> > As for log levels, is there any reason to log the implicit read attempts
> > at a level higher than "debug"? I have no opinion about the log level
> > for the explicit ones.
>
> I can see some people possibly wanting this information for auditing purposes.
> There may be organizations that have to prove their access rules work and it
> can such logging could be useful for that. But I agree that it should be
> limited to elevated logging levels.
It would be nice if the the logged message should be different in that
case, too. That is: there should be some indication, besides the
different log level, that the subrequest-generated log event is
"normal".
That is, we don't want this:
[debug] Access denied: /private
[error] Access denied: /private
But this:
[debug] Hiding directory '/private' (Access denied)
[error] Access denied: /private
(Or some other log level instead of "debug" — I haven't thought about
what log level would be appropriate.)
Daniel
Re: Logging of subrequest authorization checks in mod_dav_svn/mod_authz_svn
Posted by Ben Reser <be...@reser.org>.
On 1/16/15 11:52 AM, C. Michael Pilato wrote:
> As for log levels, is there any reason to log the implicit read attempts
> at a level higher than "debug"? I have no opinion about the log level
> for the explicit ones.
I can see some people possibly wanting this information for auditing purposes.
There may be organizations that have to prove their access rules work and it
can such logging could be useful for that. But I agree that it should be
limited to elevated logging levels.
Re: Logging of subrequest authorization checks in mod_dav_svn/mod_authz_svn
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/16/2015 02:18 PM, Ivan Zhakov wrote:
> But I'm not sure that current behavior is the best. I'm thinking to
> implement the following logic in mod_authz_svn: use different log
> level whether access denied for subrequest or for primary request (the
> URL user actually tried to access).
>
> Does it make sense?
>
> The other open question is which error level use for these 'soft'
> access denied messages:
> a) info (Like we do for access granted messages)
> b) warning
It makes sense to me to log explicit attempts to hit an unreadable
resource differently than the somewhat unavoidable implicit attempts.
As for log levels, is there any reason to log the implicit read attempts
at a level higher than "debug"? I have no opinion about the log level
for the explicit ones.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development