subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rudy Grigar <r...@tag1consulting.com>
Subject Re: Insufficient permissions error handling
Date Fri, 04 Mar 2011 02:12:33 GMT

On Mar 3, 2011, at 4:24 PM, Johan Corveleyn wrote:

> On Thu, Mar 3, 2011 at 6:25 PM, Rudy Grigar <rudy@tag1consulting.com> wrote:
>> I worked through an issue this morning with a Subversion user that was unable to
store a password locally:
>> 
>> Authentication realm: <https://code:443> Zinch SVN Drupal
>> Password for 'dev':
>> 
>> -----------------------------------------------------------------------
>> ATTENTION!  Your password for authentication realm:
>> 
>>   <https://code:443> SVN
>> 
>> can only be stored to disk unencrypted!  You are advised to configure
>> your system so that Subversion can store passwords encrypted, if
>> possible.  See the documentation for details.
>> 
>> You can avoid future appearances of this warning by setting the value
>> of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
>> '/var/lib/hudson/.subversion/servers'.
>> -----------------------------------------------------------------------
>> Store password unencrypted (yes/no)? yes
>> At revision 2260.
>> [hudson@srv-zinch-ec2db3 devdrup.zinch.com]$ svn up
>> Authentication realm: <https://code:443> Zinch SVN Drupal
>> Password for 'dev':
>> 
>> -----------------------------------------------------------------------
>> ATTENTION!  Your password for authentication realm:
>> 
>>   <https://code:443> SVN
>> 
>> can only be stored to disk unencrypted!  You are advised to configure
>> your system so that Subversion can store passwords encrypted, if
>> possible.  See the documentation for details.
>> 
>> You can avoid future appearances of this warning by setting the value
>> of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
>> '/var/lib/hudson/.subversion/servers'.
>> -----------------------------------------------------------------------
>> Store password unencrypted (yes/no)? yes
>> At revision 2260.
>> 
>> 
>> The password wasn't actually being stored, the root of the problem being that auth/svn.simple/*
was set read-only/444 (the cause of this is still unknown).
>> 
>> I talked to Stefan (stsp) this morning in #svn and he wants to add better error handling
here when the file isn't writable instead of silently failing to store the password.  The
relevant IRC log is here: http://colabti.org/irclogger/irclogger_log/svn?date=2011-03-03#l243
>> 
> 
> I've seen this happen recently by using svnkit ([1]). I don't remember
> the exact conditions (I was experimenting with use of svnkit via
> svnant in an ant build script), but it happened only when using a
> recent version of svnkit (1.3.5, i.e. the latest version at this time;
> with svnkit 1.2.0 the problem didn't happen).
> 
> Is svnkit possibly involved somehow?
> 
> I think svnkit does this when running on unix with the "unencrypted"
> situation. It's trying to cache the password, but it won't do it
> because it's going to be stored unencrypted. After that, the file
> seems to be read-only.
> 
> -- 
> Johan
> 
> [1] http://www.svnkit.com/

svnkit isn't being used currently.  Hudson is being used to auto update the dev environment,
but it's just using a standard 'svn up' from the shell.

It's also possible that someone else reconfigured or changed this around without me knowing
-- the box that this is configured on is a bit of a moving target.  I'm more interested in
seeing an improved error message when the permissions prevent the password from being stored.

Thanks!
Rudy
Mime
View raw message