Bug 556712 - svn log requires anonymous access when using svnserve
Summary: svn log requires anonymous access when using svnserve
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: subversion
Version: 12
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-19 06:46 UTC by John Griffiths
Modified: 2010-02-22 23:39 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-02-22 22:43:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description John Griffiths 2010-01-19 06:46:49 UTC
Description of problem:
svn log does not work for users that access the repository using svnserve and authz.

Version-Release number of selected component (if applicable):
subversion-1.6.6-1.fc12.i686

How reproducible:
always

Steps to Reproduce:
1. Create a repository with access for non-system users that use svnserve to access the repository with authz and passwd for access.
2. Put rw access for users and/or groups in authz
    [/]
    @GROUP1 = rw
    @GROUP2 = rw
    user1 = rw

3. try svn log on anything in the repository.
  
Actual results:
Get an error message "svn: Item is not readable."

Expected results:
Should be able to get log info for the object(s).

Additional info:
If the directive 
    * = r
is added to the authz file, then the log command works. I actually found this solution in several places on the Internet. Here is one: http://geekgok.blogspot.com/2009/01/svn-item-is-not-readable.html

This is a security issue because it is required to open the repository for read access for everyone even if the intent is to have the repository private to the users and groups.

Comment 1 Vincent Danen 2010-01-19 17:19:47 UTC
I can't reproduce this.  What does your svnserve.conf look like?

# cat authz|grep -v '^#'
[/]
vdanen = rw

# cat svnserve.conf |grep -v '^#'
[general]
anon-access = none
auth-access = write
password-db = passwd
authz-db = authz
realm = Repo

% svn info
Path: .
URL: svn://localhost/test
Repository Root: svn://localhost/test
Repository UUID: 02f69dc1-1787-4bc7-aa16-07331f4f8a52
Revision: 0
Node Kind: directory
Schedule: normal
Last Changed Rev: 0
Last Changed Date: 2010-01-19 10:01:15 -0700 (Tue, 19 Jan 2010)

% svn log  
Authentication realm: <svn://localhost:3690> Repo
Password for 'vdanen': 
------------------------------------------------------------------------
r1 | vdanen | 2010-01-19 10:05:21 -0700 (Tue, 19 Jan 2010) | 1 line

log message
------------------------------------------------------------------------


As you can see from my authz, only vdanen has access to the repository.  Anonymous access is explicitly denied in svnserve.conf and I do not have to add "* = r" to authz (and this also works if I have "* =" in authz, which also explicitly denies access.

It's hard to debug when you're not indicating what user you're trying to do the log as (is it user1?  Are they members of GROUP1 or GROUP2?).  And also, without the svnserve.conf to look at, it is also difficult to reproduce the behaviour you're seeing.

Also, the link you cite does not say you need to provide anonymous read access in order to see the log.  What is is saying is that authz overrides svnserve.conf.  The problem he had there was that he has anon-access enabled in svnserve.conf, but he had explicitly defined an ACL for [/] to only allow @admin to have rw access (implicitly meaning that defaults are overriden and anon access is denied due to the ACL).

If you look at the svn online documentation, you'll see that svnserve.conf is for defining defaults: 

http://svnbook.red-bean.com/en/1.5/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.general

But the authz path-based authorization always takes precedence.

Again, without an svnserve.conf to look at and knowing what user you're attempting to do the log as, I can't reproduce.

Comment 2 John Griffiths 2010-01-19 21:30:18 UTC
The problem only arises if a user does not have an actual account on the repository system, i.e., the svn check out is through svn://remotehost.domain.net/svnRepos/Dummy.repo/dummy and not svn+ssh://remotehost.domain.net/svnRepos/Dummy.repo/dummy so that the access goes through svnserve. All local users and ssh users do not have the problem.


Here is the svnserve.conf file for the repository.

### This file controls the configuration of the svnserve daemon, if you
### use it to allow access to this repository.  (If you only allow
### access through http: and/or file: URLs, then this file is
### irrelevant.)

### Visit http://subversion.tigris.org/ for more information.

[general]
### These options control access to the repository for unauthenticated
### and authenticated users.  Valid values are "write", "read",
### and "none".  The sample settings below are the defaults.
# anon-access = read
# auth-access = write
### The password-db option controls the location of the password
### database file.  Unless you specify a path starting with a /,
### the file's location is relative to the conf directory.
### Uncomment the line below to use the default password file.
password-db = passwd
### The authz-db option controls the location of the authorization
### rules for path-based access control.  Unless you specify a path
### starting with a /, the file's location is relative to the conf
### directory.  If you don't specify an authz-db, no path-based access
### control is done.
### Uncomment the line below to use the default authorization file.
authz-db = authz
### This option specifies the authentication realm of the repository.
### If two repositories have the same authentication realm, they should
### have the same password database, and vice versa.  The default realm
### is repository's uuid.
realm = CCIF

[sasl]
### This option specifies whether you want to use the Cyrus SASL
### library for authentication. Default is false.
### This section will be ignored if svnserve is not built with Cyrus
### SASL support; to check, run 'svnserve --version' and look for a line
### reading 'Cyrus SASL authentication is available.'
#use-sasl = true
### These options specify the desired strength of the security layer
### that you want SASL to provide. 0 means no encryption, 1 means
### integrity-checking only, values larger than 1 are correlated
### to the effective key length for encryption (e.g. 128 means 128-bit
### encryption). The values below are the defaults.
# min-encryption = 0
# max-encryption = 256
#min-encryption = 128

[miscellany]
global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store build dist target private
enable-auto-props = yes

[auto-props]
*.c = svn:eol-style=native;svn:keywords=Date Author Id Revision HeadURL
*.cpp = svn:eol-style=native;svn:keywords=Date Author Id Revision HeadURL
*.h = svn:eol-style=native;svn:keywords=Date Author Id Revision HeadURL
*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
*.sh = svn:executable;svn:eol-style=LF;svn:keywords=Date Revision
*.cmd = svn:mime-type=text/plain;svn:eol-style=CRLF
*.bat = svn:mime-type=text/plain;svn:eol-style=CRLF
Makefile = svn:eol-style=native;svn:keywords=Date Author Id Revision HeadURL
*.obj = svn:mime-type=application/octet-stream
*.bin = svn:mime-type=application/octet-stream
*.bmp = svn:mime-type=image/bmp
*.class = svn:mime-type=application/java
*.doc = svn:mime-type=application/msword
*.exe = svn:mime-type=application/octet-stream
*.gif = svn:mime-type=image/gif
*.gz = svn:mime-type=application/x-gzip
*.jar = svn:mime-type=application/java-archive
*.jelly = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision
*.jpg = svn:mime-type=image/jpeg
*.jpeg = svn:mime-type=image/jpeg
*.pdf = svn:mime-type=application/pdf
*.png = svn:mime-type=image/png
*.tgz = svn:mime-type=application/octet-stream
*.tif = svn:mime-type=image/tiff
*.tiff = svn:mime-type=image/tiff
*.zip = svn:mime-type=application/zip
*.txt = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision
*.xml = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Date Revision
*.ent = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision
*.dtd = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision
*.vsl = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision
*.xsd = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Date Revision
*.xsl = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Date Revision
*.wsdl = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Date Revision
*.htm = svn:mime-type=text/html;svn:eol-style=native;svn:keywords=Date Revision
*.html = svn:mime-type=text/html;svn:eol-style=native;svn:keywords=Date Revision
*.css = svn:mime-type=text/css;svn:eol-style=native;svn:keywords=Date Revision
*.js = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision
*.jsp = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision
*.txt = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision
*.java = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision
*.properties = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision
*.sql = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date Revision

Comment 3 Vincent Danen 2010-02-01 18:19:42 UTC
Ok, I understand this a bit better.

The problem is that on an svn log, when you have "anon-access = read" in svnserve.conf, the svn client does not ask for authentication when connecting to the repo.  If you have "anon-access = none" then you will always be asked for authentication.

This isn't so much a security problem as it is a configuration problem.  The problem you're stating is:

>This is a security issue because it is required to open the repository for read
>access for everyone even if the intent is to have the repository private to the
>users and groups.

Yet you define "anon-access = read" which tells subversion it shouldn't be asking for authentication information on read's.  I think the logic is a little strange, but that doesn't make it a security issue.

If the intent is to have a fully private repository, change svnserve.conf to "anon-access = none" and you will always be asked for authentication.  By having "anon-access = read" and not having "* = r" in authz, it doesn't matter if the user is known to the local system, even on a local system connecting to "svn://localhost" a valid system user will get the same error:

% svn log
------------------------------------------------------------------------
r2 | (no author) | (no date) | 1 line


------------------------------------------------------------------------
r1 | (no author) | (no date) | 1 line


------------------------------------------------------------------------
% svn info
Path: .
URL: svn://localhost/repos
Repository Root: svn://localhost/repos
Repository UUID: fe7aa989-c7cc-49ca-827b-475ba0536ce7
Revision: 2
Node Kind: directory
Schedule: normal
Last Changed Author: vdanen
Last Changed Rev: 2
Last Changed Date: 2010-02-01 10:53:39 -0700 (Mon, 01 Feb 2010)

If you are on the same system and you do "svn co file:///svn/repos" or some such, then the svnserve restrictions don't apply and you can do the log properly.

In your case, you probably want to remove "* = r" from authz and change "anon-access = read" to "anon-access = none" in svnserve.conf.  That will force authentication on all operations.

I tested this with two Fedora 12 instances, on the svn server I had one user (vdanen) and on the client I had two users (vdanen and joe).  With every configuration option, the restrictions were the same for the local vdanen and the remote joe (there is no joe user on the server) -- the only difference was when vdanen on the lserver did a check out with file:///... rather than svn://localhost/..

Maybe look at the output of "svn info" on the account you claim this works for without authentication?  Also try the anon-access changes and see if that solves the problem.  You should never have to make a repository readable by everyone if you don't want to, but you have two conflicting configuration options (making a repository only rw to explicit users/groups, but making anon-access have the read option set when instead it should be set to none for a fully private repository).

I do not see a security issue or even a bug here.  From my testing, this is clearly a configuration issue.  Can you try and report back?  Thanks.

Comment 4 John Griffiths 2010-02-22 22:43:32 UTC
I agree. Not a bug. Sorry. I missed that the default is anon-access = read . Made 
anon-access = none and all is well.

The reason I reported it is that I Googled the issue and there were several reports of others having the same issue and the general solution was to add * = r with no mention of changing the default anon-acces in the configuration file.

Thank you for the clarification. At least now this is documented so others may have access to your kind solution to the configuration issue.

Comment 5 John Griffiths 2010-02-22 22:45:06 UTC
Suggest unchecking security issue so the visibility is open to all. I tried and could not.


Note You need to log in before you can comment on or make changes to this bug.