Re: Insufficient permissions error handling

On Thu, Mar 3, 2011 at 6:25 PM, Rudy Grigar <rudy_at_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_at_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/