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

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Blocker
    • Resolution: Fixed
    • subversion-plugin
    • None
    • Linux, Ubuntu Hardy and Jaunty, Solaris

    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

            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.

            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.
            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.

            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.

            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.

            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.
            salsa Sami Salonen added a comment -

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

            salsa Sami Salonen added a comment - Subversion plugin 1.45 (and its new svnkit library 1.7.6) no longer overwrite authentication credentials.
            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.

            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

              kohsuke Kohsuke Kawaguchi
              tkrah Torsten Krah
              Votes:
              56 Vote for this issue
              Watchers:
              54 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: