3

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

Huckle
  • 975
  • 2
  • 8
  • 30

3 Answers3

5

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.

Community
  • 1
Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
  • +1 for the permissions not being preserved, even if you manage to give access to a non root user. – psusi Mar 06 '16 at 21:21
  • 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 Mar 06 '16 at 22:34
  • 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? – Huckle Mar 06 '16 at 22:37
  • @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. – Gilles 'SO- stop being evil' Mar 06 '16 at 22:39
  • 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. – Huckle Mar 06 '16 at 23:09
  • In order to allow the normal user `backup` to be able to view the files it does not own, I would need to use `bindfs -r -g backup -p g+rD` to create a view of the filesystem where the backup user sees files with the group set to `backup`. It will not preserve the original group and will not accurately reflect group permissions in the backup, but the original owner will be preserved. – Huckle Mar 06 '16 at 23:11
  • I'm currently reading into your ACL link to see if that would be an better approach (better meaning it could also preserve group ownership/ permissions) – Huckle Mar 06 '16 at 23:21
  • @Huckle ACL don't work for your use case, because if a file lacks the requisite entry, it won't be backed up. – Gilles 'SO- stop being evil' Mar 06 '16 at 23:26
  • It's all pros and cons. But in my case I do think I favor having a complete backup over having the correct permissions in that backup. Although maybe can get around requiring users to be compliant by allowing the backup user to set the requisite file ACLs to grant himself read access (possibly via `cron` or possibly via a sudoers file entry). – Huckle Mar 06 '16 at 23:31
1

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

mifritscher
  • 409
  • 2
  • 8
-4

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.

MelBurslan
  • 6,836
  • 2
  • 24
  • 35
  • When you say "root equivalent" account, what do you mean, exactly? – Huckle Mar 06 '16 at 04:35
  • 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. – cas Mar 06 '16 at 06:38
  • 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. – Gilles 'SO- stop being evil' Mar 06 '16 at 16:05
  • Also, ssh commands like rsync or scp won't work if the user's shell is `/sbin/nologin`. – ki9 Jul 19 '21 at 01:28