> -----Original Message-----
> From: Bogdan B. Rudas [mailto:bogdan.rudas_at_nivalnetwork.com]
> Sent: Tuesday, June 23, 2009 10:43 AM
> To: users_at_subversion.tigris.org
> Subject: AuthzSVNAccessFile and single read-only user.
> I have set of repos under Apache 2.2 https server with SVN 1.5.1
> I use LDAP authentification to for users.
> I would like to limit one special user to read-only access, we use
> user for automated checkout.
> I try with config:
> rouser = r
> * = rw
My observation has been that at any level, a user is granted the union
of all access specified. If not specified at a given directory level,
then parent paths are used.
So you could have
* = rw
rouser = r
and specify this for every directory at the top level. It still will
not prevent rouser from creating new directories under the root, though.
Of course you could have a read-only group and a read-write group and
naturally avoid overlapping permissions. But this flexibility (full
path-based authentication) does require you to list all your users in
the authz file.
I know of one other trick you can possibly apply, which is to set up
your httpd-ssl.conf to use two configurations. One configuration
specifies the read-only configuration and points to the authz file. The
other is full read-write access, and bypasses the authz file, or else
uses a different authz file. We use this for our admins to be able to
write to tags and other restricted locations. To do it you should just
have to configure two <Location> sections with duplicate SVNPath or
SVNParentPath, and separate configuration of the AuthzSVNAccessFile (or
Note that if you do this, the read-only users have a different URL for
access than the read-write users. Hopefully you can manage that
possible source of confusion. In your case (automated checkout) it is
probably nothing to worry about. If you were creating a WC this way and
intended to modify and commit from it later, I think you would have to
svn switch --relocate
to point it back at the read-write URL.
Caveat: My site uses NTLM instead of LDAP for Subversion so I don't
know whether LDAP can do anything more sophisticated than what I have
described above, nor whether it even applies to LDAP.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-23 19:18:30 CEST