> -----Original Message-----
> From: Ivan Zahariev [mailto:rrdtool_at_famzah.net]
> Sent: vrijdag 15 januari 2010 7:46
> To: David Glasser
> Cc: dev_at_subversion.apache.org
> Subject: Re: More strict file permissions for the administrative ".svn"
> directories
>
>
> You can always "chgrp $COMMON_GROUP .svn" directories and make all
> users
> have this $COMMON_GROUP as their Group ID. This way they can still
> share the ".svn" directories and still "others" (like the Web server)
> won't be able to go in there.
>
> You are right about the problem if someone chmod()'s the permissions to
> something wrong but the operators' mistakes are usually a factor which
> you cannot completely circumvent. What if they delete the ".svn"
> directories by mistake... The power of users/admins is unlimited, our
> task is to create better security principles by default.
>
> 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?
Bert
Received on 2010-01-15 09:38:08 CET