* Timo Wendt <twendt@online.de> [2006-04-13 17:10:35]:
> I have evaluated Subversion for the last few days. The features are
> really great. My problem with it are the security things in some
> areas. There are a lot of nice features when you connect to the
> repository remotely. From 1.3.1 you don't even need Apache anymore to
> use the features from authz. But to my idea Subversion lacks a lot of
> security when it comes to local access to the repository via
> file:///. All I can to is hook scripts for commits and such things.
> But what if I like no access.
Not integrating authz in the file:// access method is a deliberate
decision. The reason is simple: if you're accessing the repository
through the file RA, you must have permission to read and write all
files within the repository (the physical files on your disk I mean -
not the ones actually stored within the repository).
So, if authz denies you access, there is absolutely nothing stopping
you from going in and editing the files manually, or with a modified
svn client which ignores authz configurations. Implementing authz in
this case would be akin to building a solid titanium door on a house
with no walls: nothing stops you walking right round the locks.
There is really not much that can be done against this. The file RA
method was written because it is a relatively simple RA (no
client/server logic involved), and because it provides a very simple
solution to users who want to version data in a single-user,
single-machine scenario.
For more complex scenarios (multiple users, multiple network
locations), two server applications have been implemented. These can
be configured so that they are the only ones with direct access to the
repository storage area, so that they can enforce the security policy
given in the configuration.
> Of course I did change the permissions of the repository dirs., but
> thats about it. The book always states that umask is
> important. Umask is something the Admin cannot force. Every user
> can change his umask if he wants to. I want to place config files in
> the repository that are confidential. I cannot rely on users having
> to set there umask correctly.
Which is why you should in that case use one of the two RA servers,
that provide isolation between the repository data and the users.
> Another thing that bothers me is the auth cache and it even on per
> default. Saving clear text passwords on disk is bad. In my case the
> file was even world readable even thogh the book states it is only
> readable by the owner. I understand that this feature is nice for
> usage, but is there no way of shutting it off completely apart from
> changing the source code, which I did? As long as this feature is
> available, users will use it. Users always find nice ways to make
> their work easiest.
This is directly addressed in the FAQ on the website:
http://subversion.tigris.org/faq.html#plaintext-passwords
Also, something which the reply does not point out is that we are
progressively offering integration with desktop keyring services. I
know that we have this on OS X, and it should be possible to
contribute patches for other desktops which provide this service, such
as Gnome or KDE.
Secure storage of passwords is a hard problem if you want to do it
right. That's basically the reason we don't implement this
ourselves, and let external storage mechanisms do it for us, when it
is possible. When it is not possible, we do offer the option to turn
off password caching completely, as explained in our FAQ.
> Don't misunderstand me, this product is really great, but please also
> understand my point of view.
I hope I've replied adequately to your concerns. If you have more
concerns, I'll be happy to discuss those as well.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 13 17:52:12 2006