Apache httpd 2.4 + Subversion 1.9.5 + LDAP combination does not work on CentOS 7.x

[Ravi Roy]

Hi

I've been using Apache httpd 2.2.23 with Subvesion 1..6.21 with LDAP on
CentOS 5.11 (old setup) for years now. Recently we planned to upgrade to
Subversion 1.9.x with Apache httpd 2.4.x, i've prepared the setup as per
the following with LDAP support :

1) compiled and installed Apache 2.4.16 from source
2) compile and installed Subversion 1.9.5 from source


I've the following snippet in my httpd config which works in old setup
perfectly but in the new setup it does not work at all, It can not control
the repo access:

<Location /svn/MyRepo>
DAV svn
SVNPath /var/repos/svn/MyRepo.
Satisfy any
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
Order allow,deny
Allow from all
AuthzLDAPAuthoritative on
AuthType Basic
AuthName "Please use your Username and Password:"
AuthLDAPBindDN "CN=Ac,OU=All Users,OU=myOU,DC=mydomain,DC=com"
AuthLDAPBindPassword mypass
AuthLDAPURL "ldap://mydomain.com:3269/dc=m
ydomain,dc=com?sAMAccountName?sub?(objectClass=*)
<http://mydomain.com:3268/dc=mydomain,dc=com?sAMAccountName?sub?(objectClass=*)>
"
AuthBasicProvider ldap
AuthUserFile /dev/null
AuthzSVNAccessFile /var/repos/permissions/permfile.txt
</Location>

permfile.txt
========

[groups]
write-perm1 = user1, user2

[/]
@write-perm1 = rw
* =


After removing "AuthzLDAPAuthoritative on" (which is removed in Apache
httpd 2.4.x), it allows any ldap user to access the repo (which i do not
want). I want permfile to control the access to repo, but i could not see
an effective way to enable it.
Can somebody help here please?

Regards
Ravi.

[Branko Čibej]

Post by Ravi Roy
Hi
I've been using Apache httpd 2.2.23 with Subvesion 1..6.21 with LDAP
on CentOS 5.11 (old setup) for years now. Recently we planned to
upgrade to Subversion 1.9.x with Apache httpd 2.4.x, i've prepared the
1) compiled and installed Apache 2.4.16 from source
2) compile and installed Subversion 1.9.5 from source
I've the following snippet in my httpd config which works in old setup
perfectly but in the new setup it does not work at all, It can not
<Location /svn/MyRepo>
DAV svn
SVNPath /var/repos/svn/MyRepo.
Satisfy any
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
Order allow,deny
Allow from all
AuthzLDAPAuthoritative on
AuthType Basic
AuthName "Please use your Username and Password:"
AuthLDAPBindDN "CN=Ac,OU=All Users,OU=myOU,DC=mydomain,DC=com"
AuthLDAPBindPassword mypass
AuthLDAPURL
"ldap://mydomain.com:3269/dc=mydomain,dc=com?sAMAccountName?sub?(objectClass=*)
<http://mydomain.com:3268/dc=mydomain,dc=com?sAMAccountName?sub?%28objectClass=*%29>"
AuthBasicProvider ldap
AuthUserFile /dev/null
AuthzSVNAccessFile /var/repos/permissions/permfile.txt
</Location>
permfile.txt
========
[groups]
write-perm1 = user1, user2
[/]
@write-perm1 = rw
* =
After removing "AuthzLDAPAuthoritative on" (which is removed in Apache
httpd 2.4.x), it allows any ldap user to access the repo (which i do
not want). I want permfile to control the access to repo, but i could
not see an effective way to enable it.
Can somebody help here please?

You should remove these lines:

Satisfy any
Order allow,deny
Allow from all
AuthUserFile /dev/null


then add

Satisfy all


I also suggest you add the HEAD method to the LimitExcept directive.

-- Brane

[Ravi Roy]

Post by Ravi Roy
Satisfy any
Order allow,deny
Allow from all
AuthUserFile /dev/null
then add
Satisfy all
I also suggest you add the HEAD method to the LimitExcept directive.

Thanks Branko for quick response, i've added updated configuration as
mentioned above and restarted the httpd server, but it is not asking for
authentication information, it is still allowing the users which are not in
permfie to access the repo.

Regards
Ravi.

[Ravi Roy]

Post by Ravi Roy
Satisfy any
Order allow,deny
Allow from all
AuthUserFile /dev/null
then add
Satisfy all
I also suggest you add the HEAD method to the LimitExcept directive.

As this does not work and bypassing AuthzSVNAccessFile and gives repo

access to all valid users which exsits in LDAP directory. Does somebody
know why it is causing this? Thanks
Ravi.

[Branko Čibej]

Post by Ravi Roy
Satisfy any
Order allow,deny
Allow from all
AuthUserFile /dev/null
then add
Satisfy all
I also suggest you add the HEAD method to the LimitExcept directive.
As this does not work and bypassing AuthzSVNAccessFile and gives repo
access to all valid users which exsits in LDAP directory. Does
somebody know why it is causing this? Thanks
Ravi.

I have a practically identical configuration (with slightly more complex
access rules) and it does work for me. I suggest you turn on verbose
logging in httpd and check the logs to see what's happening.

My config looks like this:

RedirectMatch permanent ^(/repos)$ $1/
<Location /repos/>
AuthType basic
AuthName "Subversion"
AuthBasicProvider ldap

AuthLDAPUrl "ldaps://ldap.example.com/ou=people,dc=example,dc=com?uid"
AuthLDAPGroupAttribute memberUid
AuthLDAPGroupAttributeIsDN off
AuthLDAPBindDN cn=admin,dc=example,dc=com
AuthLDAPBindPassword "example.com"

<RequireAll>
Require valid-user
<Limit HEAD GET OPTIONS PROPFIND REPORT>
<RequireAny>
# Read access
Require ldap-group cn=dev,ou=group,dc=example,dc=com
Require ldap-group cn=dev.readonly,ou=group,dc=example,dc=com
</RequireAny>
</Limit>
<LimitExcept HEAD GET OPTIONS PROPFIND REPORT>
<RequireAny>
# Write access
Require ldap-group cn=dev,ou=group,dc=example,dc=com
</RequireAny>
</LimitExcept>
</RequireAll>

DAV svn
SVNParentPath /srv/repos
SVNListParentPath on
SVNPathAuthz short_circuit
AuthzSVNAccessFile file:///srv/repos/admin/access.conf
</Location>



-- Brane

[Stefan Sperling]

Post by Branko Čibej

Post by Ravi Roy
Satisfy any
Order allow,deny
Allow from all
AuthUserFile /dev/null
then add
Satisfy all
I also suggest you add the HEAD method to the LimitExcept directive.
As this does not work and bypassing AuthzSVNAccessFile and gives repo
access to all valid users which exsits in LDAP directory. Does
somebody know why it is causing this? Thanks
Ravi.

I have a practically identical configuration (with slightly more complex
access rules) and it does work for me. I suggest you turn on verbose
logging in httpd and check the logs to see what's happening.

I suspect the use of mod_auth_compat is Roy's problem here.
His config is using a 2.2-style authorization config.

Not upgrading authorization configs to the new 2.4 syntax
can cause surpises.
Read the fine manual at http://httpd.apache.org/docs/2.4/upgrading.html
and live happily ever after :)

Post by Branko Čibej
RedirectMatch permanent ^(/repos)$ $1/
<Location /repos/>
AuthType basic
AuthName "Subversion"
AuthBasicProvider ldap
AuthLDAPUrl "ldaps://ldap.example.com/ou=people,dc=example,dc=com?uid"
AuthLDAPGroupAttribute memberUid
AuthLDAPGroupAttributeIsDN off
AuthLDAPBindDN cn=admin,dc=example,dc=com
AuthLDAPBindPassword "example.com"
<RequireAll>
Require valid-user
<Limit HEAD GET OPTIONS PROPFIND REPORT>
<RequireAny>
# Read access
Require ldap-group cn=dev,ou=group,dc=example,dc=com
Require ldap-group cn=dev.readonly,ou=group,dc=example,dc=com
</RequireAny>
</Limit>
<LimitExcept HEAD GET OPTIONS PROPFIND REPORT>
<RequireAny>
# Write access
Require ldap-group cn=dev,ou=group,dc=example,dc=com
</RequireAny>
</LimitExcept>
</RequireAll>
DAV svn
SVNParentPath /srv/repos
SVNListParentPath on
SVNPathAuthz short_circuit
AuthzSVNAccessFile file:///srv/repos/admin/access.conf
</Location>
-- Brane

[Nico Kadel-Garcia]

The complexities of HTTPD/mod_auth_svn integration and its complex
integration alterations between releases of Subverison are only some
of the reasons I gave up on HTTP based access to Subversion years ago,
and switched to svn+ssh. There are uses for web access to Subversion,
but most of them are better served by the cleaner interface of viewvc
for pure read-only access.

The other blocking factor, for me, was the default behavior of the
Subversion client of storing the HTTP or HTTPS access passwords in
cleartext. It's gotten better orver time, notifying users better of
the risks, but the default behavior is still an issue.

[Stefan Sperling]

Post by Nico Kadel-Garcia
The other blocking factor, for me, was the default behavior of the
Subversion client of storing the HTTP or HTTPS access passwords in
cleartext. It's gotten better orver time, notifying users better of
the risks, but the default behavior is still an issue.

Nico, you have been repeating this point over and over again
like a broken record. I expect every subscriber to this list
is already very much aware of your opinion on this matter ;-)

The prompt (which I added years ago) was an improvement, yes.
But I don't expect this default behaviour (prompt) to change, ever,
and I see no reason to keep discussing this point. It's many years
too late for that now.

The default behaviour can be adjusted globally by the system admin with
a small config file in /etc/subversion. OpenBSD has been installing such
a file for many years and there has never been any complaint.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/subversion/files/servers?rev=1.1&content-type=text/x-cvsweb-markup
I recommend you do the same on systems you maintain, and move on.

[Nico Kadel-Garcia]

Post by Stefan Sperling

Post by Nico Kadel-Garcia
The other blocking factor, for me, was the default behavior of the
Subversion client of storing the HTTP or HTTPS access passwords in
cleartext. It's gotten better orver time, notifying users better of
the risks, but the default behavior is still an issue.

Nico, you have been repeating this point over and over again
like a broken record. I expect every subscriber to this list
is already very much aware of your opinion on this matter ;-)

Yup. I don't do it every week, or even every month. Frankly, as
Subversion has been falling in popularity, it's become less critical.
This subscriber is new, and having difficulty with Apache
configurations. Since that's so often been so awkward, and this is
*another* reason to migrate away from it, I made sure that *he*
thought about the functional, less complex to integrate, and by
default more secure svn+ssh.

Branko, some of the same risk occurs for SSH users who use passphrase
free SSH keys. The default of "ssh-keygen" to produce such keys, by
default, without a mandatory commandline option saying "yes, yes, I
really wanted no passphrase!" is a similar but not identical issue.

Post by Stefan Sperling
The prompt (which I added years ago) was an improvement, yes.
But I don't expect this default behaviour (prompt) to change, ever,
and I see no reason to keep discussing this point. It's many years
too late for that now.

Because there are occasionally new users and new admins. Admittedly,
most of the new admins are supporting legacy tools such as Subversion
in a legacy environment as they migrate to various more modern
distributed source control system. But every single new user
encounters this dangerous default unless their local client
environment has been hand-tweaked by someone with more security
conscious policies.

I do appreciate that you updated the default to at least warn about
the risk. See my above note about SSH keys without passphrases. I'm
afraid that even with the warning, it's not always enough, but it at
least allows a typical admin or user installing software to say "I put

Post by Stefan Sperling
The default behaviour can be adjusted globally by the system admin with
a small config file in /etc/subversion. OpenBSD has been installing such
a file for many years and there has never been any complaint.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/subversion/files/servers?rev=1.1&content-type=text/x-cvsweb-markup
I recommend you do the same on systems you maintain, and move on.

"System admins" do not typically have control of user's local systems
to enforce such a change in the clients, and it's pretty useless on
the Subversion server unless they all log in there with shell access
and check out material into local working copies. Admins usually only
have such control over the servers. (Been there, done that, it pays my
salary for the last 29 years.) The success of such a default change in
OpenBSD's package installed client suggests that people would accept
it for other operating systems. Perhaps we could have a very separate
thread bout whether it's time to change that default, finally, for the
next major release? Is thee a 1.10, or a 2.0 in the planning stages?

[Nathan Hartman]

Post by Nico Kadel-Garcia
Yup. I don't do it every week, or even every month. Frankly, as
Subversion has been falling in popularity,

I think that's like the BSD is dying myth. While it's true that hype, Linus's blessing, and the availability of GitHub have taken a big chunk of the F/OSS world by storm, there are still plenty of people, projects, and businesses that use Subversion. We recently evaluated other systems which shall remain nameless just to make sure we're on top of goings on in our industry and our experiences reaffirmed why we use Subversion. In a decade of use, zero problems. It's mature, it does what it's supposed to do, and it's simple to use. We like it. So do numerous other people.

[Nico Kadel-Garcia]

On Wed, Jul 19, 2017 at 11:04 PM, Nathan Hartman

Post by Nathan Hartman

Post by Nico Kadel-Garcia
Yup. I don't do it every week, or even every month. Frankly, as
Subversion has been falling in popularity,

I think that's like the BSD is dying myth. While it's true that hype, Linus's blessing, and the availability of GitHub have taken a big chunk of the F/OSS world by storm, there are still plenty of people, projects, and businesses that use Subversion. We recently evaluated other systems which shall remain nameless just to make sure we're on top of goings on in our industry and our experiences reaffirmed why we use Subversion. In a decade of use, zero problems. It's mature, it does what it's supposed to do, and it's simple to use. We like it. So do numerous other people.

I didn't say Subversion was dying. I said it was falling in
popularity, which is consistent with the surveys I can find. And dear
lordie, it's consistent with my professional and amateur software
development experience. I've seen *one* new repo started or built from
scratch under Subversion since 2006. I've seen approximately 1000
software projects or repos started or built from scratch under another
source control system, which shall remain unnamed but which hosts my
Subversion RPM building tools, I've also helped with roughly half a
dozen funded projects migrating *away* from Subversion in that time. I
help out new admins and users on the group out of appreciation, not
because it's funded or because the userbase is growing.

The local HTTP credential storage is a longstanding sore point, I
admit, which is why I *didn't* harp on it. I mentioned it as a
specific security issue, in passing, which a new HTTPS Subversion
administrator may not have considered. And I mentioned it as leverage
to migrate away away from the httpd server integration. The httpd
server integration has traditionally been one of the most awkward
parts of Subversion server support, as the original poster was
noticing quite painfully.

[Nathan Hartman]

Post by Nico Kadel-Garcia
On Wed, Jul 19, 2017 at 11:04 PM, Nathan Hartman

Post by Nico Kadel-Garcia
Yup. I don't do it every week, or even every month. Frankly, as
Subversion has been falling in popularity,

I think that's like the BSD is dying myth. [snip]

I didn't say Subversion was dying. I said it was falling in
popularity, which is consistent with the surveys I can find.

Thanks for clearing that up. It's unfortunate that you've seen those
effects. I really think they're due to the reasons I mentioned in the last
post, which are based on perception, not actual merit such as capability or
ease of use.

Is there potential for improvement? Always. But is it the terrible system
proponents of that other nameless system love to claim it is? Absolutely
not! I use a very simple test. This isn't rocket science: Ten years with
Subversion, ZERO problems since day one. With That Other System (tm)...
Well, we might be stupid. Maybe we are. But Subversion has never failed us.
Hype and perception notwithstanding, that says a lot to me.

[Daniel Shahaf]

Post by Nico Kadel-Garcia
This subscriber is new, and having difficulty with Apache
configurations. Since that's so often been so awkward, and this is
*another* reason to migrate away from it, I made sure that *he*
thought about the functional, less complex to integrate, and by
default more secure svn+ssh.

Asking people whether they had considered svn+ssh:// would be reasonable.

Offering unbiased comparisons of svn+ssh:// and https:// would be reasonable.

Repeatedly preaching your personal preference, even in threads where use
of https:// is mentioned in passing, is not acceptable. We have been asking
you for years to stop that, and we're asking you again now.

You are, of course, entitled to prefer whichever network protocol you wish,
and for that matter, you're entitled to run for Prime Minister / President
on a platform outlawing the use of ra_serf. We won't stop you from doing
any of that; we just ask you to take your preaching elsewhere and keep this
list as a source of unbiased advice.

Daniel