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).

• G-Man Says 'Reinstate Monica': Related: How can I create a user with read-only access to all files (i.e., root without writing permissions)?

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.

• psusi: +1 for the permissions not being preserved, even if you manage to give access to a non root user.
• Huckle: I agree a snapshotting mechanism would be best. Especially one that is integrated with the filesystem. However, it's a bit overkill for my current application. I happen to know one half of the backup contains torrents, which are effectively read only and the other half is git repositories, which are content-addressable file systems. A back in the middle of a git operation might result in loosing the last commit of a single repo, but its unlikely if I setup the backup job for the middle of the night.
• Huckle: If I run the rsync command from the backup server, then I could in theory use BindFS and a non-priviledged user on the host being backed up. The backup job can run as root from the backup server, which should allow it to maintain ownership and permissions?
• Gilles 'SO- stop being evil': @Huckle I don't understand what you're suggesting, but I suspect the answer is no. If rsync is connected over the network, all that matters here is what user it runs as on the machine with files to back up.
• Huckle: What I was suggesting was running rsync from the server that will store the backups, rather than from the server where the original data lives. If I run sudo -a rsync backup@hostname:/path /path then rsync will change the permissions and ownership on the backup server to match the original files, while only using the normal user backup on the server with the original data.

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.

• Huckle: When you say "root equivalent" account, what do you mean, exactly?
• cas: another account with uid=0 - e.g. on freebsd it's standard to have the root account (uid=0) AND a toor account (also uid=0, but with sh or bash rather than tcsh as its shell). both accounts are root, because the kernel cares only about the uid, not the name. there's nothing (except sanity and restraint :) stopping you from having as many such root accounts as you like. BTW, this is not a loophole around the common warning "don't login as root", uid 0 is root no matter what login name it happens to have.
• Gilles 'SO- stop being evil': What's this about a "root equivalent account"? If it has UID 0, it's root, no matter how it's called in /etc/passwd. If this user is running the rsync commands, then root is running the rsync commands, and having an extra line in /etc/passwd is pointless.
• ki9: Also, ssh commands like rsync or scp won't work if the user's shell is /sbin/nologin.