On 11/21/13 10:37 AM, sbre...@hotmail.com wrote:
> 1. Any user accessing Subversion has to be authenticated against the Unix
> password database. Works.
> 2. Before we hit the Subversion module I would like to authorize the user
> against the file system. Does not work.
>
> I have repositories l
Ben Reser wrote on Fri, Nov 22, 2013 at 10:58:39 -0800:
> So in the soon to be released 1.8.5 and 1.7.14 we are filling in the filename
> on the request_rec with svn:/path/to/repo/path/in/repo. For instance if you
> swapped svn: with file:// you'd be able to use this as a URL to a svn command
> on
sbre...@hotmail.com wrote on Thu, Nov 21, 2013 at 18:37:21 +:
> I am very happy with the SSH + 'svnserve' access to my repositories,
> however due to firewall issues I need access through HTTP as well.
> What I do not want is to set up a 2nd authentication / authorization
> database.
What are
On 11/22/13 2:56 PM, Daniel Shahaf wrote:
> Might not be a bad idea then to make the artificial/invalid
> request_rec.filename value look less like a URL then? Just in case it
> ends up in someone's "(gdb) p" output, or in a log file, etc.
>
> For example, "svn+invalid:/usr/local/svn/ppt/trunk".
Ben Reser wrote on Fri, Nov 22, 2013 at 15:16:10 -0800:
> On 11/22/13 2:56 PM, Daniel Shahaf wrote:
> > Might not be a bad idea then to make the artificial/invalid
> > request_rec.filename value look less like a URL then? Just in case it
> > ends up in someone's "(gdb) p" output, or in a log file,
On 11/22/13 3:20 PM, Daniel Shahaf wrote:
> How about "dav_svn:/" then? That's consistent with mod_proxy's
> precedent you cite and not similarly-confusing to the "svn://" URL
> scheme.
Yeah I probably should have used that but it's a little late for that since the
release is already rolled and a
Ben Reser wrote on Fri, Nov 22, 2013 at 15:22:44 -0800:
> On 11/22/13 3:20 PM, Daniel Shahaf wrote:
> > How about "dav_svn:/" then? That's consistent with mod_proxy's
> > precedent you cite and not similarly-confusing to the "svn://" URL
> > scheme.
>
> Yeah I probably should have used that but i
svn+ssh relies on SSH being directly available, by default port 22.
SSH, by default, allows direct user logins with shell access, by
password or by SSH key. That raises serious security concerns. The
safest way to run svn+ssh is usually with a separate SSH daemon, on
another port, configured to on
inadvertent
complications.
B.
> Date: Sat, 23 Nov 2013 01:07:16 +0200
> From: d...@daniel.shahaf.name
> To: sbre...@hotmail.com
> CC: users@subversion.apache.org
> Subject: Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights
>
>
ions.
>
>
> B.
>
>
>> Date: Sat, 23 Nov 2013 01:07:16 +0200
>> From: d...@daniel.shahaf.name
>> To: sbre...@hotmail.com
>> CC: users@subversion.apache.org
>> Subject: Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + fi
e...@hotmail.com
> > CC: users@subversion.apache.org
> > Subject: Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights
> >
> > sbre...@hotmail.com wrote on Thu, Nov 21, 2013 at 18:37:21 +:
> >> I am very happy with the SSH + 'svnserve' access to my repo
t;
>>
>> > Date: Sat, 23 Nov 2013 01:07:16 +0200
>> > From: d...@daniel.shahaf.name
>> > To: sbre...@hotmail.com
>> > CC: users@subversion.apache.org
>> > Subject: Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file sy
Nico Kadel-Garcia wrote on Mon, Nov 25, 2013 at 05:56:14 -0500:
> use the authorized_keys ForceCommand access
Minor correction: ForceCommand is a sshd_config(5) directive; the
authorized_keys variant is spelled 'command="..."'.
Good point, thank you!
On Mon, Nov 25, 2013 at 3:41 PM, Daniel Shahaf wrote:
> Nico Kadel-Garcia wrote on Mon, Nov 25, 2013 at 05:56:14 -0500:
>> use the authorized_keys ForceCommand access
>
> Minor correction: ForceCommand is a sshd_config(5) directive; the
> authorized_keys variant is spelled
14 matches
Mail list logo
