Greg Hudson <ghudson_at_MIT.EDU> writes:
> I agree with Kristian here, and this is probably an oversight on my part
> when I wrote the code (although it's been a while). If the passwd file
> is unreadable, svnserve should just fail to authenticate anyone with
> passwords, so that the same repository can be used with svn+ssh and
> svnserve.
(I'm assuming "unreadable" would include "doesn't exist".) Kristian's
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=121502
makes sense to me.
But if there is a readable Subversion 'passwd' file, how should
svn+ssh:// interact with it? Not at all? Or if the same username is
present in the passwd file, then should password authentication also be
done?
-Karl
> On Tue, 2008-04-29 at 17:55 +1000, Kristian Kauper 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
---------------------------------------------------------------------
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 18:00:57 CEST