Re: Security features, path based authorization in subversion

I am not too sure how you're doing things now, so let's go over the
four different repository access methods:

file://
We all agree that you want to avoid this method.

svn://
This uses the "svnserve" process. In this case, the "svnserve" process
can run as its own user and have completely private access to its
repository. No user can access the repository except through "svn://".
The disadvantage with this method is that you must use a separate
authentication file. This file can be setup to be only readable by the
svnserve process, but you're stuck maintaining it.

svn+ssh://
The advantage of this system is that it can use the OS's
authentication system. The disadvantage is that it works by creating a
separate svnserve process for each user. Any user who has access to
the repository via svn+ssh:// also has access (if they can log into
the box) with file:/// access too. There are all sorts of tricks to
keep users out of a shell when setting up ssh, but if your users need
shell access to that box, you're out of luck.

http://
Like svn://, this allows the repository to be owned by the same user
which is running the httpd daemon process. Usually, you use Apache's
authentication method to setup users which is the same drawback of
svn://. However, you can use LDAP as your verification system, so the
passwords and user names are on your LDAP server.

We have such a system setup at our place. The LDAP server is our
Windows server. If you are under a particular LDAP group, you have
read access to our Subversion repository. If you are using Unix or
Linux, you can setup an LDAP server that interacts with your
/etc/passwd file (or your NIS database). This can be done either by
having the /etc/passwd file generated from your LDAP server, or by
having your LDAP server read in entries from your /etc/passwd file.

I think what you may want to do is setup an Apache httpd daemon, and
use LDAP as your authentication system. Of course, that will involve
some major system administration which might be beyond your realm, but
if your users have shell access to the same box that has your
Subversion repository server, you can't use svn+ssh. And, your only
other choice would be using svn://, and having to maintain a separate
authentication system where you setup the passwords and accounts.

--
David Weintraub
qazwart_at_gmail.com
On Mon, Aug 25, 2008 at 5:55 AM, vinay i <vinay.indresh_at_gmail.com> wrote:
> Thanks David.
> But my concern is when I use svnserve as a user and set permissions on the
> repository, to authenticate other users I will have to store users and
> corresponding passwords. This is a security concern. Can't we have a method
> where we don't have to store passwords?
>
> Vinay
>
> On Fri, Aug 22, 2008 at 9:17 PM, David Weintraub <qazwart_at_gmail.com> wrote:
>>
>> n Fri, Aug 22, 2008 at 3:30 AM, vinay i <vinay.indresh_at_gmail.com> wrote:
>> > Hi
>> > I tired using svnserve and apache for security features and path based
>> > authorization. But when a user has access to the server (login to the
>> > server) all these authorization fails. He can access any path within the
>> > repository by file:/// access.
>>
>> Create a NEW user called "svnserve". Create a new group for this user
>> and call it "svnserve" too. Then, change all the files in the
>> repository to be owned by this user and this user's group with a
>> permission of "rw-r--r--" or even better "rw-r-----". Set this
>> svnserve's umask to "066". Then run your Subversion server as this
>> user. This way, developers can't read and write to the repository
>> using the "file:///" access.
>>
>> The only reason you should be using "file:///" access is if you have a
>> private repository, and you don't want to run the server. As soon as
>> more than one person needs access the repository, you should setup a
>> special subversion server user and give that user exclusive read and
>> write access on the repository.
>>
>> --
>> David Weintraub
>> qazwart_at_gmail.com
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org