Package Details: duplicati-canary-bin 2.0.9.110-1

Git Clone URL: https://aur.archlinux.org/duplicati-canary-bin.git (read-only, click to copy)
Package Base: duplicati-canary-bin
Description: A free backup client that securely stores encrypted, incremental, compressed backups on cloud storage services and remote file servers
Upstream URL: http://duplicati.com
Licenses: MIT
Conflicts: duplicati, duplicati-latest
Provides: duplicati
Replaces: duplicati-latest
Submitter: valandil
Maintainer: valandil
Last Packager: valandil
Votes: 61
Popularity: 1.40
First Submitted: 2022-12-12 02:40 (UTC)
Last Updated: 2024-11-13 01:49 (UTC)

Latest Comments

« First ‹ Previous 1 .. 16 17 18 19 20 21 22 23 24 25 26 Next › Last »

carbolymer commented on 2017-09-26 12:50 (UTC) (edited on 2017-09-26 12:51 (UTC) by carbolymer)

@valandil Not quite. If you're using duplicati on a headless server: 1) you have to expose the web interface 2) you cannot use duplicat-user.service which starts duplicati GUI Having exposed webserver running as a root is a security risk. If you're still not convinced to run duplicati.service as separate user, we can leave it as it is. I've added conf file to my systemd drop-in folder which sets the user and group of duplicati process, so I'm good. ;)

valandil commented on 2017-09-21 14:21 (UTC)

In that case, I think that the status quo might be a good solution. If the user wants to run Duplicati to backup his personal files, the user-privileged duplicati-user.service is sufficient. To backup system files, I don't think there is a good way around running as root. Temporary elevation of privilege would be nice, but there doesn't seem to exist a way to do in Duplicati. The user should understand that by starting duplicati.service, he is running a local webserver as root. In any case, any attack on this local web server presupposes a compromised system. The local Duplicati server itself cannot be used as a remote entry point for an attack, as it is not exposed to the Internet. I'm not sure how having a duplicati user and bindfs deters an attacker which already has access to the machine by some other means. Do you agree?

carbolymer commented on 2017-09-21 06:02 (UTC)

@valandil It seems that packages for other distros are running duplicati as root: https://github.com/duplicati/duplicati/tree/master/Installer Moreover, duplicati with the snapshot-policy=auto tries to make disk snapshots using LVM which requires root. https://github.com/duplicati/duplicati/wiki/FAQ It looks that root priviledges are required in some cases. @valandil, what's your opinion?

valandil commented on 2017-09-20 15:36 (UTC)

How do the other distros manage this? We can surely learn from them. I agree that running as root can be problematic: if an exploit is found in Duplicati, it has read AND write access to system files. I think the best way would be provide only read access to the duplicati user, with the possibility to run the server as root for restoring backups only. Not sure how to implement that so it's simple for the end-user though.

carbolymer commented on 2017-09-20 08:25 (UTC) (edited on 2017-09-20 08:30 (UTC) by carbolymer)

@dalto I understand your use case, but still I insist on pushing my change to improve security. You can use bindfs (http://bindfs.org/) to mount multiple users directories with the apropiate rights to allow backups. If you still want to run duplicati as root, I would suggest using systemd "drop-in" folder to override the settings from the .service file https://www.freedesktop.org/software/systemd/man/systemd.unit.html to avoid overwriting by each upgrade.

dalto commented on 2017-09-19 22:43 (UTC)

@carbolymer I understand why, in general, you don't want processes to run as root. However, in the specific case of a backup and restore product, it needs to run as root to be useful. In an ideal world, the control server would run as an unprivileged user and a separate process that handled the backups could run as a privileged user. However, Duplicati doesn't seem to be architected that way. It seems to me there are two common use cases for a product like this. The first is to backup/sync a specific subset of files, most likely owned by a specific user account. The second is performing broader system backups. In neither of those cases is running as a duplicati user useful. In the first case you most likely will want the process to run as your user account which would be the purpose of the existing user service. In the latter, you need it to run as root or equivalent. While it might be possible to add the user to every group on the system or overwrite it's uid to 0, both those actions would serve to decrease security, not increase it.

carbolymer commented on 2017-09-19 16:18 (UTC) (edited on 2017-09-19 16:18 (UTC) by carbolymer)

@dalto https://askubuntu.com/a/16179 You can still configure duplicati to have access to the files, for example, by using group rights.

dalto commented on 2017-09-19 16:10 (UTC)

I still don't fully understand the plan here. duplicati is a backup system. Isn't it fairly typical for a backup system to have some components that run as root in order to access the files? How are system backups to be performed without root access?

carbolymer commented on 2017-09-19 12:49 (UTC) (edited on 2017-09-19 12:49 (UTC) by carbolymer)

My idea is to create a new user, and just a notification after update with the information that database has to be moved manually to the new location. Here's the patch: https://gist.github.com/carbolymer/6cfe2209e543ba29766b8815d94dac06 I didn't want to push this commit yet, because I wanted to get your opinion first.

valandil commented on 2017-09-18 14:57 (UTC)

Good question. I guess the new user would have to be able to read system files. Restoring would be an issue though...

« First ‹ Previous 1 .. 16 17 18 19 20 21 22 23 24 25 26 Next › Last »