[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

--non-interactive and keyrings

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 02 Feb 2012 16:58:56 +0000

If I have passwords stored in the GNOME keyring and the keyring is
unlocked Subversion will read the passwords even when --non-interactive
is passed. However if I have passwords stored in the KDE wallet and the
wallet is open Subversion will not read the stored passwords when
--non-interactive is passed.

http://subversion.tigris.org/issues/show_bug.cgi?id=4110

I can fix kwallet with this patch:

Index: subversion/libsvn_auth_kwallet/kwallet.cpp
===================================================================
--- subversion/libsvn_auth_kwallet/kwallet.cpp (revision 1239705)
+++ subversion/libsvn_auth_kwallet/kwallet.cpp (working copy)
@@ -192,7 +192,12 @@ kwallet_password_get(const char **password,
 {
   if (non_interactive)
     {
- return FALSE;
+ QString wallet_name = get_wallet_name(parameters);
+ if (!KWallet::Wallet::isOpen(wallet_name))
+ return FALSE;
+
+ /* Is there a race here? The wallet is open right now, but will
+ it still be open when we come to use it below? */
     }
 
   if (! dbus_bus_get(DBUS_BUS_SESSION, NULL))

However I am worried about the TOCTOU race. There is a small window
between isOpen and the subsequent readPassword during which the wallet
may get closed. This might cause --non-interactive to attempt to prompt
the user for a password.

The GNOME keyring code suffers from the same race, there is a small
window between checking whether the keyring is locked and getting the
passwords from the keyring. The GNOME code also does the check earlier
in the call stack, so the window is potentially longer than in the KDE
case.

Do these small races matter? Should we abandon attempts to use the
keyrings with --non-interactive?

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-02-02 17:59:34 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.