borg2: Improve handling of lock files owned by another user

PhrozenByte

I ran into the following error with `borg2 repo-list` today: ``` PermissionError: [Errno 13] Permission denied: '/run/media/daniel/larissa/Borg/locks/6b85cfc4a9c0696e5ef3c5d5ed193ea54fa03690fa5bbd83236b37f11f076703' ``` This is **not a Borg bug**, but rather caused by my use case and how I create backups with Borg: Since my backup script needs to create LVM snapshots and read files that are normally inaccessible to my unprivileged user, I run the backup script as `root` via `sudo`. The repo itself, however, belongs to my unprivileged user `daniel`. My backup script fixes the ownership of the repo at the end using `chown`. Consequently, during the backup process, the repo can temporarily contain a mixture of files owned by `daniel` and files owned by `root`. This can also affect Borg's lock files. Since lock files are created with mode 0600, my unprivileged user cannot read a lock file created by `root`. This causes the `PermissionError` above. The error is technically correct, but since running Borg as `root` and later restoring the ownership is a relatively common use case, it might be worth handling this situation more gracefully. **Suggestion** If Borg finds a lock file that is not owned by the running user, it should raise an explicit error message instead of a low-level `PermissionError` exception. Borg should refuse to operate on the repo, regardless of the lock type or whether the lock is considered stale, because a lock file owned by a different user is itself an indication that the repo's ownership or permissions are inconsistent, and proceeding could potentially be unsafe. Additionally, it might be a good idea to create lock files with mode 0644 instead of 0600. The `locks/` directory itself is 0700 and belongs to the repo owner. Thus, making the individual lock files readable by everyone would not expose them to arbitrary users (and, in any case, they do not contain any sensitive data); access to the directory would still restrict access to the repo owner and `root`. However, it would allow the repo owner to read a lock file created by other users and let Borg report more details about the situation.

ThomasWaldmann

Note: Usually the `umask` should be used to control the mode of newly created files. In borg 1.x, we had an `--umask` option for `borg serve` - check if that exists / works also for borg master branch.

ThomasWaldmann

A good workaround for your problem would be to use a `ssh:` repository, even if it sshs just to `daniel@localhost`: - the borg client runs as root - `borg serve` runs as the unprivileged user, so you don't need to chown repo files at all Alternatively, there might be also an approach using capabilities, so that an otherwise unprivileged borg client can still read all the files. IIRC there is already a ticket or even documentation about this.

PhrozenByte

> Note: Usually the `umask` should be used to control the mode of newly created files. Changing Borg's default 0200 umask is not a viable alternative here, because 0600/0700 permissions are indeed the right choice for almost all files and directories Borg creates. The permissions should only be different for lock files. > A good workaround for your problem would be to use a `ssh:` repository, even if it sshs just to `daniel@localhost` Also see #9764. IMO, `chown`ing the files is currently the easiest and least error-prone workaround. > Alternatively, there might be also an approach using capabilities, so that an otherwise unprivileged borg client can still read all the files. I'm aware of the capabilities approach (it is in the docs already), but I don't think it is widely used, nor do I think it is a good solution to begin with. Allowing an unprivileged user to run a specific command with limited functionality (the backup script) as root is generally preferable to granting an unprivileged user root-like permissions to read arbitrary files. Besides, bootstrapping tasks like creating LVM snapshots might still require full root permissions.