I completely agree that it will be best if there is only one ".svn"
directory, because we can easily change its security policy to suit each
one's needs.
It seems that SVN 1.7 will resolve my current security concerns, so I
guess I'll have to wait for its stable release.
Until then I'll either manually patch the 1.6.x releases or intercept
every mkdir(".svn") request with an LD_PRELOAD hack and chmod() the
directory myself.
Thanks for all your comments, keep up the good work!
---
P.S. The portability issues you describe exist even now - if you want
access for your Web server which is hosted on such an "advanced file
system" which work with ACLs, then you are stuck with the same problem -
having to give ACL on each ".svn" folder for the Web server; unless the
FS supports the "others" mask ;).
I suspect that most of the Subversion server usage is on POSIX-compliant
file systems which support the permissions for "others". But let's not
waste time to discuss this any further.
Bert Huijben wrote:
-----Original Message-----
From: Ivan Zahariev [mailto:rrdt...@famzah.net]
I think the best way to achieve this security improvement is by making
the ".svn private permissions" as an option in the "~/.subversion"
config files.
Or this is too much work and we'd better take the risk that ".svn"
directories are world-accessible?
This would be a change that can't be backported to 1.6.x. (Would change the
configuration file, which is nearly impossible under our versioning policy).
It also has the potential of breaking other applications if it would be
enabled by default. (E.g. a website that reads its own metadata to show some
versioning information, but which is only 'svn update'd by another user)
With 1.7 and WC-NG the entire working copy infrastructure changes so to a
single .svn directory inside (or optionally outside) your working copy,
which would make this change unnecessary.
Another issue with the suggested approach is platform portability. Only
plain unix filesystems work with these masks; many other operating systems
and more advanced filesystems work with access control lists. How would you
handle these?
