#1549 Password Safe v3.57 does not load config file from UNC path

[Mitch Ames]

Password Safe v3.57 64-bit does not load config file correctly from UNC path. (It worked OK in v3.55)
Can be reproduced on all of :

• Password Safe running on Windows 7 SP1 64-bit, connected to network server running Windows 7 SP1 64-bit
• Password Safe running on Windows 7 SP1 64-bit VirtualBox virtual machine, connected to directory shared from host
• Password Safe running on Windows 10 or Windows 10 Server, connected to network server running Windows 10 Server

Create a portable instance (using v3.55 first, to prove it works), thus:

On a new machine, extract all the Password Safe v3.55 files into a new directory (call it the "portable directory")
In that directory run
pwsafe -u mitch -h portable -g pwsafe.cfg
at the prompt, click "yes" to create the .cfg file, then create a new database pwsafe.psafe3 in the portable directory.
Change the configuration so that it is easily distinguished from the defaults. I used

• Hide toolbar and dragbar
• Do not put icon in system tray (so application closes when window closes)
  Exit Password Safe

Note that the PWS_PREFSDIR environment variable is not set.

To make it easy to run from anywhere, add portable.cmd to the portable directory, containing this line:
start "(title)" "%~dp0pwsafe.exe" "%~dp0pwsafe.psafe3" -u mitch -h portable -g pwsafe.cfg

"(title)" is a placeholder, required because I need quotes around the .exe to allow for spaces in the directory name, but "start" assumes that the first thing in quotes is a title. "%~dp0" is the directory containing portable.cmd

Put this portable directory onto a shared network location, with write access.
Now I can run portable.cmd from anywhere, including without it being the current directory, which is useful when I don't want to map the network directory to a drive letter. It works perfectly at v3.55.

But when I update to v3.57 it does not work properly if run from a network, eg
\\VBOXSVR\Temp\password-safe-portable-357\portable.cmd
it ignores pwsafe.cfg in the portable directory and uses the default configuration, creating and using %localappdata%\PasswordSafe\pwsafe.cfg
This is the case even when I run portable.cmd from a shortcut that specifies the "start in" directory as the portable directory, or if I specify that directory as the start directory in the command script:
start "(title)" /d "%~dp0" "%~dp0pwsafe.exe" "%~dp0pwsafe.psafe3" -u mitch -h portable -g pwsafe.cfg

I thought perhaps the default directory for "-g pwsafe.cfg" had changed, so I updated my cmd script to specify it:
start "(title)" "%~dp0pwsafe.exe" "%~dp0pwsafe.psafe3" -u mitch -h portable -g "%~dp0pwsafe.cfg"
but this does not make any difference to the behaviour.

If I specify PWS_PREFSDIR in the script, it does work:

set PWS_PREFSDIR=%~dp0
start "(title)" "%~dp0pwsafe.exe" "%~dp0pwsafe.psafe3" -u mitch -h portable -g pwsafe.cfg

Also - presumably related - with the original script (and no PWS_PREFSDIR), if I put the portable directory into a local drive or map a drive letter for the network drive, then run it from a different location, it creates %localappdata%\PasswordSafe\ but does not use it. (Whereas v3.55 did not, in these scenarios.) Eg from a command prompt in C:\

c:\password-safe-portable-357\portable.cmd
z:\password-safe-portable-357\portable.cmd

[Rony Shapiro]

I couldn't reproduce this problem using the Visual Studio debugger.

The relevant code hasn't changed since 2017, though, so perhaps the problem is in the Windows environment?

[Mitch Ames]

I couldn't reproduce this problem using the Visual Studio debugger.

Can you (or anyone else) reproduce the problem with the standalone release build?

The relevant code hasn't changed since 2017, ...

v3.56 includes bug fix SF1542 "UNC paths now accepted as backup directory", which might possibly be related.
That being said, I just tested 3.56 and it appears to work OK. My problem only appears in 3.57.

perhaps the problem is in the Windows environment?

I can reproduce the problem, in a variety of different environments. In the case of the original 3 scenarios, the two Win7 machines were both home machines created and configured by me, so could possibly have the same oddity that caused the problem, but the Win10 machines were created and configured by someone else, in a corporate network environment.

Adding to the list of other environments in which I can reproduce the problem:

• Pwsafe running on Windows 10 from a portable directory shared from a Windows 7 remote desktop client. I run Win7 (this machine has the portable Password Safe directory) then Remote Desktop to Win10 box and login. From Win10, run "\tsclient\C\Mitch\password-safe-portable-357\portable.cmd"
• Pwsafe running on a clean install of Windows 7 Pro SP1 from a portable directory shared from a similar clean install of Win7, both VMs. The only changes to Windows after installing from the DVD are installation of VirtualBox Guest Additions, turning on network discovery, and sharing the directory over the (virtual) network.
• Pwsafe running on a clean install of Windows 10 Pro 20H2 from a portable directory shared from a similar clean install of Win10, both VMs. The only changes to Windows after installing from the DVD are turning on network discovery, and sharing the directory over the (virtual) network.

In all cases, v3.55 and 3.56 work as expected, 3.57 fails, with no changes to the environment, only to the pwsafe binaries.

I'm happy to do some more testing to try to track down the problem, so let me know if there's something specific I can check.

[Rony Shapiro]

1. The fix for SF1542 is unrelated to configuration file logic.
2. I can reproduce the problem from the command line with a release build of PasswordSafe, but not with the debug build. This makes debugging this a bit challenging...
3. Can you see if UNC paths are problematic in other places where PasswordSafe accepts a file path as input?

[Mitch Ames]

I tried specifying a UNC path for a file to encrypt, and that works OK:

\\VBOXSVR\Temp\password-safe-portable-357\pwsafe -e \\VBOXSVR\Temp\password-safe-portable-357\file.dat

However it looks like the UNC path to config file does not work correctly in earlier versions for all scenarios. Eg 3.55

set PWS_PREFSDIR=
C:\temp\password-safe-portable-355\pwsafe C:\temp\password-safe-portable-355\pwsafe.psafe3 -u mitch -h portable -g \\VBOXSVR\Temp\config-only\pwsafe.cfg

creates and uses C:\temp\password-safe-portable-355\pwsafe.cfg (which did not exist beforehand, for this test) instead of \\VBOXSVR\Temp\config-only\pwsafe.cfg (which did exist)
3.56 behaves the same. However in the same scenario 3.57 creates and uses %localappdata%\PasswordSafe\pwsafe.cfg (which did not previously exist) instead of \\VBOXSVR\Temp\config-only\pwsafe.cfg (which did exist)

If I specify the UNC directory in PWS_PREFSDIR I get the same results in 3.55:

set PWS_PREFSDIR=\\VBOXSVR\Temp\config-only\
C:\temp\password-safe-portable-355\pwsafe C:\temp\password-safe-portable-355\pwsafe.psafe3 -u mitch -h portable -g pwsafe.cfg

creates and uses C:\temp\password-safe-portable-355\pwsafe.cfg (which did not exist beforehand, for this test) instead of \\VBOXSVR\Temp\config-only\pwsafe.cfg (which did exist)
3.56 behaves the same.
However in this scenario, 3.57 works correctly, using \\VBOXSVR\Temp\config-only\pwsafe.cfg

If I specify the directory in PWS_PREFSDIR but do not specify the config file name at all it works correctly for all of 3.55, 3.56, 3.57, eg

set PWS_PREFSDIR=\\VBOXSVR\Temp\config-only\
C:\temp\password-safe-portable-357\pwsafe C:\temp\password-safe-portable-357\pwsafe.psafe3 -u mitch -h portable

correctly uses \\VBOXSVR\Temp\config-only\pwsafe.cfg for all three versions.

In case it matters, in all tests in today's post I was running from a command line z:\pwsafe, where z:\ is a network drive that does not contain any of the password safe files (binary or config)
All of today's tests are on a Windows 7 SP1 64-bit VirtualBox VM, running on a Windows 7 SP1 64-bit host, and \\VBOXSVR is created by VirtualBox "shared folders".

[Mitch Ames]

I just downloaded the source code for v3.56 and 3.57 and compared them. PWSprefs::FindConfigFile() has changed, in particular from:

    if (sDrive.empty() || sDir.empty())
      m_configfilename = sExecDir + sFile + sExt;

to

    if ((pws_os::IsWindows() && sDrive.empty()) || sDir.empty())
      m_configfilename = sCnfgDir + sFile + sExt;

This is probably (part of?) the problem.

Note that IsWindows && sDrive.empty might be assuming that Windows paths always have drive letters - but UNC paths do not have drive letters.

[Mitch Ames]

It's possible that the Help file needs updating regarding
Password Safe Preferences, in particular the location of pwsafe.cfg.
Is the statement "By default, pwsafe.cfg is kept in the same directory as the pwsafe.exe
executable program" necessarily true now? I suspect that (even if the directory is writeable) the software will read the file from the exe directory only if it already exists, but if it does not already exist it is created in %localappdata%\PasswordSafe by default.

[Mitch Ames]

Also in pwsafe-3.57.0-src\src\core\PWSprefs.cpp I see

} else { // User specified config file via SetConfigFile()
// As per pre-use of Local AppData directory,
// If file name's relative, it's expected to be in the
// os-specific config directory
stringT sDrive, sDir, sFile, sExt;
pws_os::splitpath(m_configfilename, sDrive, sDir, sFile, sExt);
if ((pws_os::IsWindows() && sDrive.empty()) || sDir.empty())
m_configfilename = sCnfgDir + sFile + sExt;
}

However that does not look right. Should it be
sDrive.empty && sDir.empty
and a comment of "if filename only...", rather than "filename is relative"?

The code as it stands (on a Windows machine) will not use sDrive if sDir is empty, and not use sDir if sDrive is empty. Eg given either "test\pwsafe.cfg" or "d:pwsafe.cfg" (or in my case, "\\server\share\path\pwsafe.cfg") the code will apparently use sCnfDir\pwsafe.cfg

Note that the help file says, for -g config_file "If just a filename is given, without a path, ..." If a relative path were given, I would expect it to be relative to the current directory (as per normal conventions) not the preferences directory, unless you explicitly stated otherwise in the help file.

[Rony Shapiro]

Right. The confusion arose in part because in the distant past PasswordSafe stored the config file in the same directory as the executable file.
Fixed the code by cleaning it up - the relative path was already made absolute for Windows, so the entire if statement was wrong. Also updated the help file - thanks for pointing it out.

Commit c99b3a494 - will be in next release.

[Mitch Ames]

OK thanks

Also updated the help file

Remember to search the entire help file for references to pwsafe.cfg and updated them if necessary - I just noticed one in the Filter section: "... autoload_filters.xml in the same
directory as the pwsafe.cfg file (by default the directory where Password
Safe is installed)"

[Rony Shapiro]

Right. The confusion arose in part because in the distant past PasswordSafe stored the config file in the same directory as the executable file.
Fixed the code by cleaning it up - the relative path was already made absolute for Windows, so the entire if statement was wrong. Also updated the help file - thanks for pointing it out.

Commit c99b3a494 - will be in next release.