Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-8059

Subversion Plugin does break native svn command line authentication, credentials missing after rewriting auth cache file

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Component/s: subversion-plugin
    • Labels:
      None
    • Environment:
      Linux, Ubuntu Hardy and Jaunty, Solaris
    • Similar Issues:

      Description

      Hudson does rewrite the authentication file under ${user.home}/.subversion/auth/svn.simple/$file and does not insert credentials stuff.
      I am using a custom build which does use the command line client (in addition to the normal svn usage of the hudson project) - so the credentials are important to be in there. My custom project is broken every time hudson does rewrite those authentication cache file from subversion.

      Is it possible to configure hudson not to do this rewrite or to insert those credentials when the rewrite does happen?

      The only workaround found is to set the immutable bit (removing write privileges is not enough) as root user to the file in question which hudson is not able to workaround (which is expected here and good).
      Project does build but the log grows with these exception trace:

      Nov 10, 2010 10:54:47 AM hudson.scm.SubversionSCM$CheckOutTask invoke
      INFO: Failed to estimate the remote time stamp
      org.tmatesoft.svn.core.SVNException: svn: Cannot rename file '/home/hudson/.subversion/auth/svn.simple/auth.d17e3535-2c01-0010-81b2-1f57b38e3f1e.tmp' to '/home/hudson/.subversion/auth/svn.simple/1755861b3f63d264955a25532195c4f8'
      at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
      at org.tmatesoft.svn.core.internal.wc.SVNFileUtil.rename(SVNFileUtil.java:552)
      at org.tmatesoft.svn.core.internal.wc.SVNWCProperties.setProperties(SVNWCProperties.java:352)
      at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager$PersistentAuthenticationProvider.saveAuthentication(DefaultSVNAuthenticationManager.java:810)
      at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.acknowledgeAuthentication(DefaultSVNAuthenticationManager.java:276)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:606)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:275)
      at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:263)
      at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516)
      at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)
      at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001)
      at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.info(DAVRepository.java:724)
      at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:698)
      at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:596)
      at hudson.FilePath.act(FilePath.java:753)
      at hudson.FilePath.act(FilePath.java:735)
      at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:589)
      at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:537)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:1119)
      at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
      at hudson.model.Run.run(Run.java:1324)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:139)

      Of cause it can not rename the file, the immutable bit is set and only the root user is able to change this or any process which got the CAP_LINUX_IMMUTABLE capability bit set - of cause my hudson process does not get this privilege.

      So anything i can do to get rid of those subversion problem without this "workaround"?

        Attachments

          Issue Links

            Activity

            Hide
            tkrah Torsten Krah added a comment -

            Nice catch @Stanislav - did not even though a second about this might be the cause, indeed all my projects use svn:externals - so i am seeing this one everytime .
            Lets hope its the cause and after it will be fixed, it never happens again.

            @Kohsuke: My comment about renaming is the same problem, because it does only want to rename the file, if credentials are going to be rewritten and the user running jenkins does not have the right (at will to not break things for other apps running native command) to rewrite the credentials - so it must fail. It would not even happen if svn does not touch the credentials and rewrite them - it does not make sense to rewrite the file and before+after the content is the same.
            It should use it as-is.

            Show
            tkrah Torsten Krah added a comment - Nice catch @Stanislav - did not even though a second about this might be the cause, indeed all my projects use svn:externals - so i am seeing this one everytime . Lets hope its the cause and after it will be fixed, it never happens again. @Kohsuke: My comment about renaming is the same problem, because it does only want to rename the file, if credentials are going to be rewritten and the user running jenkins does not have the right (at will to not break things for other apps running native command) to rewrite the credentials - so it must fail. It would not even happen if svn does not touch the credentials and rewrite them - it does not make sense to rewrite the file and before+after the content is the same. It should use it as-is.
            Hide
            naninani Stanislav Kanev added a comment - - edited

            I found more details:
            1. even when you have empty svn externals property, the native credentials are overwritten. Completely removing the property with svn propdel svn:externals . solves the issue.
            2. when I removed all auth files from ~/.subversion/auth/svn.simple/* and cleaned up the workspace the jenkins build with/without externals didint failed and was able to pick up the sources from the svn repo. So jenkins does not use the native credentials at all.
            So the usage of ~/.subversion/auth/svn.simple/* files should be removed at all from the plugin.
            I think that this issue is related to the svnkit.

            Show
            naninani Stanislav Kanev added a comment - - edited I found more details: 1. even when you have empty svn externals property, the native credentials are overwritten. Completely removing the property with svn propdel svn:externals . solves the issue. 2. when I removed all auth files from ~/.subversion/auth/svn.simple/* and cleaned up the workspace the jenkins build with/without externals didint failed and was able to pick up the sources from the svn repo. So jenkins does not use the native credentials at all. So the usage of ~/.subversion/auth/svn.simple/* files should be removed at all from the plugin. I think that this issue is related to the svnkit.
            Hide
            gnustavo Gustavo Chaves added a comment -

            If all you need is to keep Jenkins from messing with the credentials used by the command line svn, a workaround is to use a different directory for storing credentials passing the "--config-dir" to the svn command. You have to use this option consistently in every invokation, but it makes svn immune from this Jenkins's bug.

            Show
            gnustavo Gustavo Chaves added a comment - If all you need is to keep Jenkins from messing with the credentials used by the command line svn, a workaround is to use a different directory for storing credentials passing the "--config-dir" to the svn command. You have to use this option consistently in every invokation, but it makes svn immune from this Jenkins's bug.
            Hide
            salsa Sami Salonen added a comment -

            Subversion plugin 1.45 (and its new svnkit library 1.7.6) no longer overwrite authentication credentials.

            Show
            salsa Sami Salonen added a comment - Subversion plugin 1.45 (and its new svnkit library 1.7.6) no longer overwrite authentication credentials.
            Hide
            danielbeck Daniel Beck added a comment -

            As mentioned in a comment here and JENKINS-12478, this seems to have been fixed around Subversion plugin 1.45. No disputing reports since.

            If this or a similar issue occurs in Subversion plugin 2.x, please file a new issue.

            Show
            danielbeck Daniel Beck added a comment - As mentioned in a comment here and JENKINS-12478 , this seems to have been fixed around Subversion plugin 1.45. No disputing reports since. If this or a similar issue occurs in Subversion plugin 2.x, please file a new issue.

              People

              • Assignee:
                kohsuke Kohsuke Kawaguchi
                Reporter:
                tkrah Torsten Krah
              • Votes:
                56 Vote for this issue
                Watchers:
                55 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: