Thanks for your patience, everybody, while we've been busy doing other
things than fixing this very long-standing bug, which was reported four
times and relegated for a long time to a corner labeled "hmmm, what
*should* we do with this one, anyway?"
I just wrote and documented a little '/usr/bin/svnwrap' script to set
the umask to 002 before executing other svn client binaries. I will
include it in next upload (1.3.1-3) in the 'subversion-tools' package.
You can see the details in 'man svnwrap', but the short version is, if
you do the following:
that should take care of <file:///> and <svn+ssh://> URLs, and if you
use an inetd.conf line that runs '/usr/bin/svnwrap svnserve -i' instead
of just '/usr/bin/svnserve -i', that should take care of <svn://> URLs.
If you launch svnserve as a daemon (as opposed to inetd) ... well, do
the obvious thing.
NOTE NOTE NOTE: there's a security implication to doing this with
/usr/local/bin/svn (for file:/// access): it affects users' local
working copies, not just the repositories. This, by the way, is the
reason upstream has never "fixed" this issue properly by just setting
the umask inside the subversion binaries themselves. (I can explain
further, including why this only affects bdb repos - anyone interested
should probably reply privately.)
Thanks for your patience, everybody, while we've been busy doing other
things than fixing this very long-standing bug, which was reported four
times and relegated for a long time to a corner labeled "hmmm, what
*should* we do with this one, anyway?"
I just wrote and documented a little '/usr/bin/svnwrap' script to set
the umask to 002 before executing other svn client binaries. I will
include it in next upload (1.3.1-3) in the 'subversion-tools' package.
You can see the details in 'man svnwrap', but the short version is, if
you do the following:
ln -s /usr/bin/svnwrap /usr/local/bin/svn bin/svnserve
ln -s /usr/bin/svnwrap /usr/local/
that should take care of <file:///> and <svn+ssh://> URLs, and if you
use an inetd.conf line that runs '/usr/bin/svnwrap svnserve -i' instead
of just '/usr/bin/svnserve -i', that should take care of <svn://> URLs.
If you launch svnserve as a daemon (as opposed to inetd) ... well, do
the obvious thing.
NOTE NOTE NOTE: there's a security implication to doing this with
/usr/local/bin/svn (for file:/// access): it affects users' local
working copies, not just the repositories. This, by the way, is the
reason upstream has never "fixed" this issue properly by just setting
the umask inside the subversion binaries themselves. (I can explain
further, including why this only affects bdb repos - anyone interested
should probably reply privately.)
Peter