File System Permissions: User who can backup all files

Question

I am setting up an automated backup job for some computers on my network. There is a server that will, daily, run an rsync command to backup each of the other computers. I'd like the user that the rsync job runs as to be able to read everyone's home directories (including sensitive files like encrypted secret SSH keys) but not be able to write anywhere on the system (except for /tmp). I'd also like to prevent normal users from reading each other's home directories, especially the sensitive parts.

My first thought was to make a group comprising of only the backup user. Then I'd have the users chgrp their files to the backup group. Not being members themselves, they wouldn't be able to read each other's files but the backup user could read everything they wanted backed up.

However, users cannot chgrp to a group they are not a part of. I can't add them to the group since that would enable users to read each other's home directories.

I had considered giving the backup user a NOPASSWD entry in the sudoers file that allowed him to only run the exact rsync command it needs as root, but that seems potentially disastrous if I don't set it up right (if there was a way to make a symlink to /etc/sudoers and to get the rsync command to use it as a destination, for example).

Answer 1

TL,DR: run the backup as root. There's nothing wrong with authorizing the precise rsync command via sudo, as long as you carefully review the parameters; what would be wrong would be to allow the caller to specify parameters.

If you want the backup user to be able to read file, see Allow a user to read some other users' home directories The idea is to create a bindfs view of the filesystem where this user can read everything.

But the file level isn't the best level to solve this particular problem. The problem with backups made by rsync is that they're inconsistent: if a user changes file1 then file2 while the backup is in progress, but the backup reaches file2 before file1, then the backup will contain the old version of file2 and the new version of file1. If file2 is the new version of file1 and file1 is removed, that means that this file won't appear in the backup at all, which is clearly bad.

The solution to this problem is to create a snapshot of the filesystem, and run the backup from that.

Depending on your snapshot technology, there may be a way to ensure that a user can read the snapshot. If not, mount the snapshot and use the generic filesystem-based solution. And even if there is, rsync is still problematic, because if you run it as an ordinary user, it won't be able to back up ownership. So if you're backing up multiple users' directories, you need to run the backup as root.

Answer 2

Another (a bit complicated ;) ) way would be to make a read only view to the related partition (if raw partitions then kpartx -r, if lvm (preferred!) a lvm snapshot, if btrfa/zfs/whatever with builtin snapshot its functionality (preferred as well)) and give the backup user readonly rights to this. Then prepare a tiny linux in a kvm which automatically backups this partition (given via a virtual HDD) to the destination (given by e.g. p9 aka shared folders if using qemu/kvm).

Answer 3

There is only one user, i.e., root who can read any file on the system. This is the reason why any commercial backup software, requires root capability to run. There many different ways to do this but if you are going to use rsync, I'd suggest you create a root equivalent account, with the shell set to something like /sbin/nologin or equivalent and have this user run the rsync commands in a script, using cron. Going into sudoers will make thing more complicated than necessary and will open up a whole new set of issues.