[lug] setting subversion permissions with apache/mod_dav
hugh at math.byu.edu
Mon Jan 15 22:02:55 MST 2007
On Tue, 16 Jan 2007, D. Stimits wrote:
> > Tired of me yet? The solution seems to be, add "Deny from all" below
> > your "Order deny, allow"
> Sadly, this resulted in all access being denied. I'm starting to feel I
> need to rebuild apache, openssl, and subversion with debug symbols, and
> run it in a debugger. When I try to use the svn co on the command line
> after adding the Deny from all, it never even gives me a chance to
> attempt adding the pass:
> svn: PROPFIND request failed on '/svn/helloworld'
> svn: PROPFIND of '/svn/helloworld': 403 Forbidden (https://...
> SSL log:
> ... client denied by server configuration: /var/www/html/svn
> > Alternatively, you can remove the "Order deny,allow"
> Sadly, this results in totally open access to all svn clients. While
> searching for an answer on google, the only success story I found was
> from a guy that wiped his system and started over from scratch. I'm
> about ready to give up on svn with apache and run svnserve, but it won't
> do all I need...and of course there is no guarantee it won't also misbehave.
> My variation which lets everyone in:
> <Location /svn>
> DAV svn
> SVNParentPath /var/www/svn
> AuthType Basic
> AuthName "Subversion Repository"
> AuthUserFile /etc/passwd-httpd
> AuthGroupFile /etc/group-httpd
> Require group devel
> Anything with Order deny,allow, then Deny from all seems to ignore all
> attempts at login.
> You said you had looked at authz, which looks extremely useful since I'm
> hoping to eventually mix authentication for read only plus read/write
> access at some point. What kind of httpd config do you use on that? How
> about the authz file itself? And have you used the apache htpasswd
> utility to generate your password files? I know I've messed something
> up, but for the life of me I can't see it.
When doing my test environment, I installed the apache svn libraries and
the subversion packages for Debian etch. I then modified the dav_svn.conf
file that Debian provided to match the environment that you posted.
Deny from all
AuthName "Subversion Repository"
Require group devel
was what I finished with. When I had just Order deny,allow w/o Deny from
all, I got open access like you described. When I either removed the
Order deny,allow or added in the Deny from all, then I had to be a member
of the devel group in order to do anything from the command line. I also
noticed that the credentials got stored in
.subversion/auth/svn.simple/<random string> I think the ssl cert is what
gets stored in svn.ssl.server/<random string>
Since you can't log in at all and get a straight denied, I'm assuming
either cached credentials that won't go away or that the permissions
blocking access are being inherited from somewhere else in the apache set
up. If you've got time and can have the website be out of commission
while testing, I'd try disabling all but the svn portion of the apache
config to see if the login problems persist.
I'm using apache 2.0.54 on the debian box (if that makes any difference).
I did use the authz stuff and I just followed the directions in the
subversion book that is linked from tigris.org in order to set it up. I
did spend a lot of time looking at the documentation and fiddling with the
authz file trying to wrap my head around how permissions were inherited
from further up. I believe we were using apache's basic auth for the user
accounts. I don't have access to the config anymore and it was 2 years
ago that I used it/supported it (so all I have in memory is that it took
some effort to wrap my head around how it did things in more complicated
environments). It did seem to work well and do what we wanted it to.
More information about the LUG