Bug#242368: new 'svnwrap' binary

Peter Samuelson peter at p12n.org
Fri Apr 21 09:13:32 UTC 2006


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
  ln -s /usr/bin/svnwrap /usr/local/bin/svnserve

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-subversion-maintainers/attachments/20060421/35b4e5d1/attachment-0004.pgp


More information about the pkg-subversion-maintainers mailing list