Kristian Kauper wrote on 2006-11-13:
> I allow access to my repository via the svn:// scheme. So I have user
> credentials stored in my repository's "passwd" file (to be clear, this is
> subversion's passwd file, not the system passwd file). For security, I want
> the permissions on this file to be set to 0600.
>
> The problem is that I also want to support the svn+ssh:// scheme. But, when
> I try to use ssh to access the repository, SVN complains that it can't read
> the passwd file -- no kidding, I certainly don't want everyone who can log
> in via SSH (or, to be precise, those in the "svn" group) to also be able to
> read all of the subversion credentials.
>
> Is there any way around this? I certainly think this is a bug, as SVN should
> not have to read the passwd file if the user is already authenticated via
> SSH.
Assuming your server is on a POSIX machine, you could use the
setuid/setgid svnserve wrapper I recently announced
(http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=137577) to
work around this problem.
Here's how you could set it up:
1. rename svnserve to svnserve.real
2. install svnstsw (the svnserve tunnel-mode setuid wrapper I wrote)
3. create a symlink named 'svnserve' (in the PATH) that points to the
svnstsw wrapper
4. create a 'svn' group (do not add anyone to this group)
5. make 'svn' the group owner of the svnstsw executable
6. set the setgid bit on the svnstsw executable
7. set permissions on the passwd file so that only the svnserve.real
daemon you use for svn:// access and the svn group can read the passwd file
With the above setup, users wouldn't be able to read the passwd file,
yet svnserve would not complain when in svn+ssh:// mode since the setgid
bit allows it to read passwd.
Hope this helps,
Richard
Kristian Kauper recently wrote:
> Sorry! I thought I was replying to the original message thread. Here's
> Marcus's response, with links to my original email:
>
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=121507
>
> BTW, I also received this response from David Anderson:
>
> "The password storage and shell access issues with svnserve is well
> documented. The recommended course of action (if apache+mod_dav_svn is
> not an option) is to configure ssh to allow svn committer users no
> access to the machine other than execution of /usr/bin/svnserve. This
> forces all their interaction with the repository to go through the
> svnserve interface, thus preventing them from accessing anything
> directly (and certainly from getting at the configuration). Another
> recommended policy is to disallow users to set their own password for
> svnserve, but rather to autogenerate it and use the client caching
> mechanism to not have to remember it. This password then offers access
> to nothing other than the version control repository, where any
> unauthorized change can be reverted easily. All these options, and
> more, are discussed in the svn book, at http://svnbook.org ."
>
> To be honest, however, I don't think these are great suggestions. The
> first is just impractical in our environment, and I'd assume that many
> people would want to have a system that allows SSH access for both SVN
> and shell.
>
> I just don't get why this is an issue in the first place. Why does the
> code need to read the passwd file if a user has already authenticated
> via SSH? I thought that was the point of the SSH access method.
>
> David says that this issue is well documented, but for the life of me I
> couldn't find much in the way of formal documentation or mailing list
> discussions.
>
> Thanks.
>
> -K
>
> Karl Fogel wrote:
>> Kristian Kauper <kkauper_at_au.yahoo-inc.com> writes:
>>> Does anyone know if the patch that Marcus refers to ever made it into
>>> a release?
>>>
>>> Since my original query, I've upgrade to 1.4.4, but this problem still
>>> exists.
>>
>> Can you point to the original mail in the archives, so people know what
>> you're referring to? Thanks.
>>
>> -Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-29 23:03:33 CEST