SourceSVN receives "access forbidden" but credentials work fine in PowerShell

[DavidHopkinsFbr]

I'm trying to integrate MantisBT Source Integration (using the SourceSVN plugin) with a VisualSVN Server instance.

MantisBT is running in an XAMPP stack on a Windows VM. The XAMPP Apache service is running under the LocalSystem built-in Windows account. VisualSVN Server is running on another Windows VM. Both are members of the same domain. VisualSVN Server is configured to use Windows authentication. Basic authentication (Windows username/password over HTTPS) and NTLM/Kerberos authentication are both enabled. The SVN repositories are served over HTTPS.

I have created a domain user with read-only access to the VisualSVN Server repositories, for the MantisBT integration to log in as.

When I log into the MantisBT server as this user and run svn on a PowerShell prompt, it successfully authenticates to the VisualSVN Server instance and I can read log messages from the repository, perform checkouts, etc. This is using NTLM/Kerberos Windows authentication and does not result in any cached credentials being added to the svn auth store.

When I log into my laptop as a non-domain local user and run svn checkout --username mantissvnintegration --password REDACTED https://svnhost.example.com/svn/projectname, it also works. This is using basic authentication, and caches credentials in the SVN client. I'm ok with that happening for the MantisBT integration.

I have noticed that when I am running PowerShell in a domain user security context, SVN seems to ignore the --username and --password command line arguments. This may be related to my problem.

The issue is that when I configure the SourceSVN plugin to use the exact same credentials above, and try to do a full repo import of the same path, I get an application error:

APPLICATION ERROR #plugin_SourceSVN_svn_cmd Subversion execution returned an error: "svn: E170013: Unable to connect to a repository at URL 'https://svnhost.example.com/svn/projectname' svn: E175013: Access to '/svn/projectname' forbidden".

It looks like the authentication is failing when SourceSVN invokes the SVN client, even though the same credentials work ok on the PowerShell command line.

What can I do to troubleshoot this further?

[DavidHopkinsFbr]

It looks like the authentication issue exists somewhere in the SSL implementation used by the SVN client. We've decided to circumvent it by creating a dedicated Windows domain account for the XAMPP Apache service to run under, and grant that account read-only access to the VisualSVN Server repositories. (This has the side benefit of improving the security posture of the XAMPP instance).

Under this configuration, the credentials specified in the SourceSVN configuration are still ignored since they're trumped by the Windows authentication, but the integration is no longer complaining about authentication problems when I try to import everything.

[dregad]

Please note that the plugin is not the source of the error, it just reports whatever the SVN executable outputs to STDERR.

Troubleshooting suggestions:

• Add debugging code in svn_run() method, to find out the exact SVN command that the plugin is executing. For example, assuming your Mantis (>= 2.7.0) is configured with $g_log_level = LOG_PLUGIN;, add just before the proc_open() call

  plugin_log_event( $t_svn_cmd );

• Check which under which user the SVN process is running and that it can actually access your server.

[dregad]

Sorry I did not realize that you had posted a reply while I was typing mine. Can this issue be considered resolved ?

[DavidHopkinsFbr]

The current situation is that SVN no longer reports an error when I try to import the changesets, but instead Mantis appears to hang. No Mantis pages can be loaded until I restart the Apache service. I waited an hour or so, thinking it might just be processing, but it didn't come good by itself.

I can see that an svn.exe process starts on the Mantis server, but it doesn't seem to exit when done, and it doesn't respond to task kill ("Access denied"). I can't see which user account this svn.exe process belongs to, for some reason. Restarting the Apache service terminates the rogue svn.exe process.

I can see from the VisualSVN server logs that it is receiving requests from the SourceSVN plugin via the SVN client, and is responding to them with OK responses. So, as far as the server is concerned, the transactions seem to be completing successfully.

So I'm still trying to figure out what's different about the context in which the plugin is executing svn.exe, compared to running svn.exe with the same user in PowerShell directly.

Am I correct in assuming that the instance of svn.exe invoked by proc_open() should be running under the Apache service user? Or could there be a different user context involved when it's launched by proc_open()?

I'm using the "Windows start" checkbox in the plugin configuration. The Mantis log shows this, after adding the extra diagnostics you suggested:

2019-04-18 17:12 PLUGIN SourceSVN plugin_api.php:1033 plugin_log_event() start /B /D "C:\Program Files\TortoiseSVN\bin" svn.exe --non-interactive --trust-server-cert --username "" --password "" info https://svn.example.com/svn/projectname --xml 2019-04-18 17:12 PLUGIN SourceSVN plugin_api.php:1033 plugin_log_event() start /B /D "C:\Program Files\TortoiseSVN\bin" svn.exe --non-interactive --trust-server-cert --username "" --password "" log -v -r 0:HEAD --limit 200 https://svn.example.com/svn/projectname --xml

The authentication seems to be working fine now but the plugin seems to be choking on the response for some reason.

[dregad]

Am I correct in assuming that the instance of svn.exe invoked by proc_open() should be running under the Apache service user?

I've never used this under Windows so I can't say for sure, but I believe that's correct indeed.

Mantis appears to hang

You might be hitting #261 - have a look at the discussion in there, and the related issues/PR's.

[DavidHopkinsFbr]

Ok, I think this can be closed now. The authentication issues seem to have been in the SSL layer between VisualSVN Server and the SVN client, and have been resolved by changing the security context of the Apache service. The SVN hangups certainly seem to be another issue and definitely look like another instance of #261.