This PR is a security hardning change and will break some setups.
The hardning is done to ensure the datafolder is not compromised and particularly that it is not maliciously seeded.
The changes now **requires** that the datafolder is locked down with exact permissions, or Duplicati will refuse to use it. This is a change to prior functionality where the folder would simply be locked down if it was not already locked.
Previously, a file named `insecure-permissions.txt` could be placed in the folder to instruct Duplicati not to set permissions. With this change that file is no longer supported.
The only way to opt-out of the permission check is to supply `--allow-insecure-datafolder` or the environment variable `DUPLICATI__ALLOW_INSECURE_DATAFOLDER`. Once either of those are set, Duplicati will no longer check permissions and accept folders with other permissions.
The setting can be applied to `preload.json`, but the file needs to be in a trusted location, which is either the directory with the binaries or the file pointed to by `DUPLICATI_PRELOAD_SETTINGS`. The setting cannot be placed in a `preload.json` file that is in an insecure folder as the folder is not read if the permissions are not correct.
The previous paths `/usr/local/share/Duplicati/preload.json` and `C:\ProgramData\Duplicati\preload.json` are no longer supported as they cannot be guaranteed to be locked down.
A `preload.json` in the datafolder is still supported, provided the folder passes the permission check (or the `--allow-insecure-datafolder` is passed to the executable).
For most users, this should not cause any problems as Duplicati has been locking down the folders, so they should be correctly locked down already.
The configuretool has been updated with a `secure-datafolder` command that can be used to force the correct permissions on a folder, in case the folder did not have the correct permissions.
For some Docker setups it may not be possible to set the permissions and the check will fail. These setup will need to apply `DUPLICATI__ALLOW_INSECURE_DATAFOLDER=true` in the image to run without the protections.
This refactors a part of the database and adds a new "sync" command that reuses a lot of the backup logic to take a set of sources and apply them to a backend.
Unlike the backup process, the sync copies files verbatim without any encryption.
This PR changes to use relative database paths by default. The default mode is to store all databases in the same folder.
With this update, the paths stored in the server database can now be relative, in which case they are resolved relative to the datafolder.
This makes it simpler to move the data folder as the paths are not stored in full.
For new backups, relative paths are assigned.
For existing backups, the full paths are retained.
If the database path is updated manually, the path will be made relative, if it is relative to the datafolder; otherwise a full path is stored.
This fixes#6677
This PR has a large blast radius because it takes the final step and bumps up the Controller to be fully async.
We have historically done a piece-by-piece update, so all operations were already async but the controller interface was kept synchronous.
With this update, the controller is now fully async and all tests are updated.
Most places where the new C# compiler warns about function names not ending in `Async` were also adressed, giving a massive refactor change.
Functionally, no changes are done.
Adds two new commands to the database CLI tool:
- verify: Lists all databases with their status (Found, Missing, Orphaned)
across dbconfig.json, server database, and filesystem
- cleanup: Removes orphaned database files not referenced in dbconfig.json
or server database, with --dry-run and --force options
Includes unit tests for both commands.
This adds a connection string repo, where connection strings can be stored.
The general idea is that it is possible to store connection strings, say an S3 connection, and then re-use the connection string for multiple backups, editing as needed.
The implementation supports listing connection strings, creating, updating, and deleting them.
The connection strings are masked so sensitive information is not available in the browser, and the logic patches connection strings internally to ensure markers are replaced with the correct values.
The connection string itself is stored in full, such that a Duplicati version roll-back will not make the connectionstring become invalid.
There is also an endpoint that allows updating existing backups using the connection string, so it is easy to rotate keys. The logic for this feature is that it retains: scheme, port, host, path, and any extra settings on the target url.
It does not remove settings from the target, but will overwrite or add settings from the connectionstring.
This PR adds support for locking files if the backend supports it.
To activate locking, set the option `--file-lock-duration=30D` and the backup will lock the files.
If the database is rebuilt with the intention of continuing the backups, use the option `--repair-refresh-lock-info` which will update lock information in the database after recreating the database.
The locking works by asking the backend to lock files after a backup has completed.
The implementation keeps track of which files are currently assigned a lock and prevents attempting to delete the files that are currently locked.
Note that the bucket should not have a default lock policy as Duplicati needs to finish the backup before the locking is applied.
In this initial version, Azure Blob Storage, B2, S3 and iDrive are supported with locking.
The CLI is updated to allow setting locks on a specific version. The backend tool is updated to allow setting locks on specific files.
This PR adds the ability to manage backup configurations outside of the the client.
The implementation ensures that locally created configurations cannot be affected by the remotely managed backups.
If the instance is not connected to a remote console, this has no effect.
This PR updates the local database to add the column `ExternalID` that tracks backups that are managed remotely.
Kenneth Skovhede