[JIRA] Commented: (HUDSON-8059) Subversion Plugin does break native svn command line authentication, credentials missing after rewriting auth cache file

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[JIRA] Commented: (HUDSON-8059) Subversion Plugin does break native svn command line authentication, credentials missing after rewriting auth cache file

Kohsuke Kawaguchi

    [ http://issues.hudson-ci.org/browse/HUDSON-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144541#action_144541 ]

yschimke commented on HUDSON-8059:

Atlassian seemed to hit the same problem in Bamboo

The fix appears to be to take control of authentication in the App instead of via subversion authentication directory


"Last, but not least, is the fact that Bamboo uses
DefaultSVNAuthenticationManager. Personally, I think that it would be
not only safer, but also more "correct" to use custom implementation of
ISVNAuthenticationManager - this will allow to store all credentials
within Bamboo application, not as something belonging to the user. It
would be also much easier to configure repository access credentials
from Bamboo user interface and there will be no problems like [one we're
discussing currently|http://jira.atlassian.com/browse/BAM-4517] (though of course it should be fixed!)."

> Subversion Plugin does break native svn command line authentication, credentials missing after rewriting auth cache file
> ------------------------------------------------------------------------------------------------------------------------
>                 Key: HUDSON-8059
>                 URL: http://issues.hudson-ci.org/browse/HUDSON-8059
>             Project: Hudson
>          Issue Type: Bug
>          Components: subversion
>         Environment: Linux, Ubuntu Hardy and Jaunty, Solaris
>            Reporter: tkrah
>            Priority: Blocker
> 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"?

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.hudson-ci.org/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira