Thanks Richard, I'll have a play with it.
-K
Richard Hansen wrote:
> 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-30 17:17:53 CEST