Re: view log problem with path authorization
Hi Phil, Any response to this? It does look like a bug to me... *From:* Phil Crooker *Sent:* Tuesday, 24 May 2016 6:10 PM *To:* users@subversion.apache.org *Subject:* view log problem with path authorization Newbie question - I have authenticated users with read or r/w access are unable to view logs, eg: # svn --username whatever --password x svn://svn/repos/project/yada.txt svn: Item is not readable I must grant anonymous read access in authz and then it works: [/] * = r I've seen this reported earlier but no answer: http://svn.haxx.se/users/archive-2011-02/0141.shtml http://stackoverflow.com/questions/6651997/svn-show-log-not-working My question is why can't an authenticated user who has rights see the logs? Send the original reply only directly to you (rather than to the list). Hence sending again to increase the chances that this might trigger some light for someone else (and also for you in case my reply got lost somewhere): The issue seems to be on record in the SVN bugtracker: https://issues.apache.org/jira/browse/SVN-2960 . Can't say much more unfortunately. :-/ -- Regards, Stefan Hett
Re: view log problem with path authorization
On Tue, May 24, 2016 at 08:40:29AM +, Phil Crooker wrote:
> Newbie question - I have authenticated users with read or r/w access are
> unable to view logs, eg:
>
>
> # svn --username whatever --password x
> svn://svn/repos/project/yada.txt
>
> svn: Item is not readable
>
> I must grant anonymous read access in authz and then it works:
>
>
> [/]
>
> * = r
>
>
> I've seen this reported earlier but no answer:
>
>
> http://svn.haxx.se/users/archive-2011-02/0141.shtml
>
> http://stackoverflow.com/questions/6651997/svn-show-log-not-working
>
>
> My question is why can't an authenticated user who has rights see the logs?
Hi Phil,
The use case scenario behind the design of the authz feature is the following:
Imagine you're setting up a competition, where teams apply to compete
and write some piece of software for you based on a specification.
Your competition has the following contraints:
- No team should be aware of who else is competing.
- You're hosting all competing teams in a single repository.
In this scenario, the following information must be protected:
- file content
- the knowledge of which paths exist in the repository
- the knowledge of which authors make commits to the repository
'svn log' shows always the author name, and the list of changed paths
is available with 'svn log -v'. And because log messages are free-form,
they may contain content which would leak such information.
For example, developers might refer to each other in log messages
("Review by: Robert") or they might refer to paths in the repository
("team1/project1/main.c: Fix crash with --help option.")
That's why, if any path in the changed paths list of a revision is
forbidden to the authenticated user, the *entire* information which
would be provided by 'svn log' is hidden from that user.
I suspect that, in your scenario, SVN denies access to the revision
log based on the above reasoning.
RE: view log problem with path authorization
Thanks, Stefan, for the explanation. It has been very puzzling, this makes
sense now. A feature, not a bug. ;-)
From: Stefan Sperling
Sent: Monday, 30 May 2016 8:27 PM
To: Phil Crooker
Cc: users@subversion.apache.org
Subject: Re: view log problem with path authorization
On Tue, May 24, 2016 at 08:40:29AM +, Phil Crooker wrote:
> Newbie question - I have authenticated users with read or r/w access are
> unable to view logs, eg:
>
>
> # svn --username whatever --password x
> svn://svn/repos/project/yada.txt
>
> svn: Item is not readable
>
> I must grant anonymous read access in authz and then it works:
>
>
> [/]
>
> * = r
>
>
> I've seen this reported earlier but no answer:
>
>
> http://svn.haxx.se/users/archive-2011-02/0141.shtml
>
> http://stackoverflow.com/questions/6651997/svn-show-log-not-working
>
>
> My question is why can't an authenticated user who has rights see the logs?
Hi Phil,
The use case scenario behind the design of the authz feature is the following:
Imagine you're setting up a competition, where teams apply to compete
and write some piece of software for you based on a specification.
Your competition has the following contraints:
- No team should be aware of who else is competing.
- You're hosting all competing teams in a single repository.
In this scenario, the following information must be protected:
- file content
- the knowledge of which paths exist in the repository
- the knowledge of which authors make commits to the repository
'svn log' shows always the author name, and the list of changed paths
is available with 'svn log -v'. And because log messages are free-form,
they may contain content which would leak such information.
For example, developers might refer to each other in log messages
("Review by: Robert") or they might refer to paths in the repository
("team1/project1/main.c: Fix crash with --help option.")
That's why, if any path in the changed paths list of a revision is
forbidden to the authenticated user, the *entire* information which
would be provided by 'svn log' is hidden from that user.
I suspect that, in your scenario, SVN denies access to the revision
log based on the above reasoning.
--
This message from ORIX Australia might contain confidential and/or
privileged information. If you are not the intended recipient, any use,
disclosure or copying of this message (or of any attachments to it) is
not authorised.
If you have received this message in error, please notify the sender
immediately and delete the message and any attachments from your
system. Please inform the sender if you do not wish to receive future
communications by email.
The ORIX Australia Privacy Policy outlines what kinds of personal
information we collect and hold, how we collect and handle it and your
rights in regards to your personal information. Our Privacy Policy is
available on our website: http://www.orix.com.au .
We do not accept liability for any loss or damage caused by any computer
viruses or defects that may be transmitted with this message. We
recommend you carry out your own checks for viruses or defects.
