Re: More strict file permissions for the administrative ".svn" directories

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:rrdtool_at_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?