Give complete read access to a service while running it under its own account


I'm using the Duplicati AUR package to perform my backup tasks, but I believe my question is more general as it basically boils down to user rights.
The Duplicati package provides a unit file that starts the service that handles the backup engine, and that process runs under the duplicati user.
In the set of folders that I want to backup, I have added my home folder (/home/obones) the common user files (/files) and the entire /etc tree as I'd rather not loose the configuration of various system elements.

While this works fine for most elements, the service complains that it cannot access my home folder and a few items inside /etc

Looking at the access rights for my home folder, it makes perfect sense because it is set to drwx------ which clearly means that the duplicati user cannot read anything in here.

I could edit the service file to have the process run under the root account, but I'm not too happy giving the keys of the castle to a service.
Further to this, I appreciate having the ability to identify which files were created/modified by the engine during its work by simply looking at files created/owned by the duplicati user.

Would there be a way to give the duplicati user super powers while keeping from being able to modify anything but its own files?

I have read about capability bounding sets on the fail2ban wiki page here:
But I'm not sure I could use those options to do the opposite of what's described in the page, that is give more powers to a given user/process.

Thanks a lot for any suggestion.

Not that I know of.

Your options:

  1. Run the service as your own user
  2. Allow group read-access to your files and add the service user to that group
1 Like

I would suggest the same as @jonathon.
I wonder what does duplicati manual suggest about backup methods.
Isn't it possible to have more than one backup profiles/sets? One for system, one for user (on user demand)?
What about restoring? Should "system" handle user (private) data.
Don't forget Linux is multi-user designed, no matter how one uses it. Think big! :laughing:

Edit: now I've got it!

This is a Windows user "bug".
If duplicati is designed so as having a service to do system-wide (+users) data, then be it.
It can be a wonder or hesitation if it was closed source.
In Open Source, think of it like "YOU created that program". Would you wonder about yourself? :wink:

Well, this may be a "Windows user bug", but I'm not the only one thinking like this as can be seen on the above mentionned Fail2Ban wiki page.

As to the original issue, I actually solved it with the help of an ACL applied recursively on the /home/obones folder that gives read access to the duplicati user.

I know, I know... There are a lot out there :rofl: . But still a "bug", in a matter of speaking :wink:

Please give a full feedback on this. It's a case that might be needed from other users and in several different cases.

Edit: BTW, this is the proper way of doing it and should be in the program's manual/instructions.

What do you mean by that? I should suggest an edit on the wiki page?

Using ACL capabilities is powerfull, you can do a lot of fine-tuning in the security setup for personal customizing. But it's complicated and not many "normal" users are really using it, except from specific workarounds like making sddm read the user folder face.ico to present user's picture (when not using system setting).

It would be adding an example of ACL usage, if you describe your solution.
Then, we may add a Tutorial or wiki for that. :wink:

1 Like

What @petsam means is it's great you solved your issue by editing your ACL, but other than yourself no one else knows the details on how this was accomplished.

If you open a help thread on the forum and solicit assistance you should be prepared to give a detailed step by step write up on how to you fixed your issue if you find a solution.

The forum is for all users benefit not just there for one person to get help on an individual issue. It's major benefit is as a knowledge repository for all Manjaro users. You should always document any solution in a thorough manner on the forum.

It benefits all users that way, and may even help you again in the future when you forget the exact details on how you accomplished something in the past.

1 Like

Well, actually, it's quite easy to do, it takes only two commands. The first one gives access to existing files:

setfacl -P -R -m u:duplicati:r-X /home/obones/

then the second one sets a "default" ACL so that when new folders/files are created, they get the ACL:

setfacl -P -R -dm u:duplicati:r-X /home/obones/

I found this by reading the wiki page on ACLs here:

Now, the "default" one may not be required if one is using a scheduled task to perform the backup. In that case, calling the first command before any backup is started is good enough.