I’d like to understand (and know what I can safely throw away) what is in ~/.config/Duplicati (macOS)
-rw-r--r-- 1 root wheel 217088 Jan 8 13:23 Duplicati-server.sqlite
-rw------- 1 root wheel 739905536 Jan 8 07:01 WDPMLCOMGW.sqlite
-rw-r--r-- 1 root wheel 176128 Sep 7 13:59 backup 20190907015953.sqlite
-rw-r--r-- 1 root wheel 866516992 Sep 7 12:17 backup 20190907020100.sqlite
-rw------- 1 root wheel 122880 Sep 7 14:10 backup 20190907021035.sqlite
-rw------- 1 root wheel 122880 Sep 8 11:03 backup 20190908110318.sqlite
-rw------- 1 root wheel 122880 Sep 8 11:05 backup 20190908110529.sqlite
-rw------- 1 root wheel 122880 Sep 8 11:09 backup 20190908110900.sqlite
-rw------- 1 root wheel 122880 Nov 3 14:28 backup 20191103022841.sqlite
drwxr-xr-x 3 root wheel 96 Sep 7 13:59 control_dir_v2
-rw-r--r-- 1 root wheel 6 Dec 27 13:33 lock_v2
It seems to me the stuff from last September and before is old junk and could be deleted. True? (I had trouble with one of my systems with a broken backup, probably this was the one and the stuff there are leftovers. I’ve now moved to canary 34 and removed a version and all seems well again)
One way to be more sure is to figure out how many backups you’re running, look at the Database screen, and make sure you can account for all of your backups. Possibly WDPMLCOMGW.sqlite is your one and only. That’s certainly how it looks. Duplicati-server.sqlite is there for configurations, scheduling, and so on.
I’m pretty sure the old backup files aren’t being used, but you could
ls -lu for time-last-read if you want, and you could also move them elsewhere for awhile, make sure everything you run is OK, then do delete.
Could all files in ~/.config/Duplicati have POSIX permissions 600 (or 700 for directories)? That would give at least some protection to scanning for passwords in them. And I noticed that on my system some databases have 644 others have 600. Even better if .config/Duplicati could have 700 permissions.
I don’t know why that is. Any idea what you were doing differently that might explain differences?
I didn’t design or write this, but a reason Duplicati-server.sqlite is readable by other users may be:
Duplicati Tray Icon Silently Dies with --no-hosted-server arg #3137
Assuming TrayIcon on Linux is the same, it needs the password to run on password-protected UI.
I suppose one view is that Linux should be given at least the equivalent bug by tightening up here, however a Windows service problem is hard to hit because service is harder. Linux may be easier.
Not a full answer, but you can always open an issue in GitHub for comments and maybe changes.
Solidify SQLite dependencies #4024 may give another way to protect Linux a bit more. Windows is currently using System.Data.SQLite encryption, but it’s just RC4 with a usually-fixed (user-settable) password. Some refer to this as scrambling because it’s not good encryption, but it offers a little bit. Linux could perhaps attempt to follow Windows, at least to that extent. Follow linked issue for more.
Fix not revealing stored passwords from the UI [$100] #2024 got in using the various OS keychains, however volunteer resources apparently aren’t available. Even with high protection, someone could steal credentials at point of use with a debugger, but I agree the current bar to theft is set pretty low.
Duplicati is very good about protecting from untrusted remote. Local attacks are harder to defend…
I’m pretty sure there are other GitHub security issues. Things in support requests get lost over time.
I have never used ‘Tray’ and I don’t even know what it is…
/Applications/Duplicati.app/Contents/MacOS/duplicati-server with some arguments from the LaunchDaemon (as I provided elsewhere on the forum) and that is it. Everything else goes via the web interface. And since the
duplicati-server runs as root, it can access everything fine. If a user knows the password for the Web UI he/she can manage all backups. But it’s sysadmin only.
The Tray Icon
When started, the Duplicati Tray icon tool creates a small icon in the System Tray for easy access to the Duplicati Web Interface. The server component is included in the Tray Icon tool. After a default installation, the Tray Icon tool will be automatically started after a user logs on, making it unnecessary to configure the server component in an everyday use case.
EDIT: This is Windows behavior of the .MSI installer. Duplicati.WindowsService.exe can add the service if discovered and added, but non-Windows might go the other way (Tray Icon is discovered and added).
Configuring the Duplicati Tray Icon in Windows probably matches macOS, but Tray Icon might be called “duplicati” as it is on Linux (and /usr/bin/duplicati-server is a script wrapper to start Duplicati.Server.exe).
Duplicati.GUI.TrayIcon.exe has details including --no-hosted-server for those wanting a separate server. Your case can probably run fine with cutting down the permissions to root, but this isn’t always the case.
Not sure if you’ve noticed, but you found a better spot to post on the password issue, so I pointed here.
Any updates on the plaintext password security problem?
See Why do some people call the taskbar the “tray”?
Microsoft Style Guide confirms
system tray is wrong, but search shows it’s used a lot anyway…
Don’t use. Use notification area instead.
On Linux, some people call them indicators. Here’s history from a possible future indicator source.
The panel indicator area was introduced in an early version of GNOME somewhat based on the Microsoft Windows '95 design, as an area dedicated to notifications. It is often called the systray or the notification area.
Here’s a Linux one, which is similar to Windows’. Icon has a menu, and changes color and shape.
Make System Tray icon a little bit more informative is a request to do more with this, but more basic is disappearance of the currently used indicator software, slowly maybe replaced by Ayatana Indicators.
As this change progresses, even installing gets tough:
Duplicati fails to install at Centos 8 #3950
libappindicator is not part of OpenSUSE - why is it needed? #3804