On 7/31/2016 2:30 PM, Patrik Jonsson wrote:
Hi all,
I've been banging my head against this problem for a day and I need
some help. We recently updated the machine hosting our svn repo, and
this broke commits using svn+ssh. Here's the setup:
* Machine runs debian 3.16.7, svn 1.8.10.
* svn runs as user "www-data" (the apache user).
* svn+ssh access uses a forced ssh command which sudos to the
www-data user and executes an svnserve wrapper.
* svnserve wrapper sets umask to 022 and then executes "svnserve -t"
with a specific tunnel user.
This setup is identical to what it was on the old machine. However,
there must be something different about it, because now https commits
work fine, but the svn+ssh commits give the error:
Transmitting file data .svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 255) with
no output.
If I access the repository directly using file:// and sudo to the
www-data user when executing svn, commits work fine. This, in
combination with the fact that https access works, makes me conclude
it is not a permissions or hook problem on any of the files since all
these access methods run as the www-data user. Nevertheless, the error
comes from the hook, because if I remove the hook file completely, the
failure moves to the post-commit hook.
It's not a problem finding !#/bin/sh either, because I tried replacing
the hook with a compiled C program that just returns 1, and I still
got the 255 return code.
When I attempt to commit, I can see successful authentication in the
syslog, like:
sudo: <user> : TTY=unknown ; PWD=/home/<user> ; USER=www-data ;
GROUP=www-data ; COMMAND=/usr/local/bin/svnserve-wrapper
sudo: pam_unix(sudo:session): session opened for user www-data by (uid=0)
sshd[26903]: Received disconnect from <ip>: 11: disconnected by user
sshd[26897]: pam_unix(sshd:session): session closed for user <user>
The svnserve log file gets this (the name of the repo here is "test")
<user> test open 2 cap=(edit-pipeline svndiff1 absent-entries depth
mergeinfo log-revprops) / SVN/1.8.10%20(x86_64-pc-linux-gnu) -
and then nothing. (I don't know what the "open" command does, it's not
included in the list of commands on e.g.
http://svnbook.red-bean.com/en/1.8/svn.serverconfig.operational-logging.html)
I've seen some similar reports of this, but no suggestions apart from
permissions or corrupted hook files, which this can't be. I don't even
know how to proceed with debugging this. Is it possible to see what
svnserve attempts to do with the hook file? Since it's spawned on
demand, I don't know how to attach to it with a debugger, or where in
the source code this error originates.
Any ideas would be much appreciated,
Regards,
/Patrik J.
Is SELinux enabled on the new server? I've seen some oddball permission
problems result when upgrading Linux systems if SELinux is enabled on
the new server but not the old. I don't use svnserve, so I can't offer
specific advice other than the security context in which the new user
runs may be different than that of svnserve, and SELinux may be blocking
it. On Red Hat/CentOS, you would look in "/var/log/audit/audit.log" for
signs of trouble. I don't know if that is the location of the SELinux
log files under Debian.
In particular, watch out for files (scripts, configuration files) copied
directly from an older server without SELinux into a new server with
SELinux. They don't get a context appropriate to the directory in which
you put them. I use Apache, and I had to track down these files
afterward and fix them one by one - very painful. This isn't just a
Subversion problem but is a general Apache problem.
If you do have SELinux running, a quick way to determine whether you
have a security context problem is to turn SELinux off briefly.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
