How can I run an rsync backup/replication script in a user other than root while preserving permissions? This is a multi-user fileserver, where each user has a *nix account for permissions.

Running with the root user poses obvious security risk - especially when you are using passwordless ssh keys to do it automatically.

But running in a user other than root (like a backup user with full group permissions to the data directories), has problems setting permissions because only the owner or root can change permissions.

In a perfect world, the production server user would only have read-only access.



You can use fakeroot -s:

   -s save-file
          Save  the  fakeroot  environment to save-file on exit. This file
          can be used to restore the environment later using -i.  However,
          this  file will leak and fakeroot will behave in odd ways unless
          you leave the files touched inside the fakeroot alone when  out‐
          side the environment. Still, this can be useful. For example, it
          can be used with rsync(1) to back up and restore whole directory
          trees  complete  with user, group and device information without
          needing to be  root.  See  /usr/share/doc/fakeroot/README.saving
          for more details.

Rather that using a different account have you considered only allowing forced commands with your ssh key? I wrote about how to set this up for rsync on my blog a while ago.

What it means is that the ssh key could only be used to run the exact rsync command you've specified, and nothing else.

Setting up a backup user isn't something I've looked at before, but I'd expect it to be a lot more work - also, since this is a multi-user system how would you ensure that all the files were readable by this user?

  • The summary of the blog: Check out sshd's configuration option "PermitRootLogin forced-commands-only". In my original plan, a group ('backup') was created and the permissions for the user directories were set to have the 'backup' group have all permissions. Ideally, this group would be limited to read-only. I like your solution, but it would be even better if we could make the user rsync runs as have read-only access to the data. Thanks! – Craig Younkins Jul 29 '09 at 1:52
  • One downside of using the force-commands-only option is that it could possibly break functionality. The client (rsync) isn't specifying the command to be executed. I'm wondering if you can use the forced-commands-only to drop a connection into a jail, one where the client can specify the command, but only has access to the rsync binary. – Craig Younkins Jul 29 '09 at 4:38
  • Why would the rsync command change? As long as you're backing up the same data everytime the script runs this would be fine. – theotherreceive Jul 29 '09 at 6:06

I would configure an rsync server on the production system such that it allows read-only access to the production data.

Something like this would handle that:

# cat /etc/rsyncd.conf
uid = nobody
gid = nobody
use chroot = yes
max connections = 4
syslog facility = local5
pid file = /var/run/rsyncd.pid

  path = /path/to/prd_data
  comment = Production data
  read only
# grep rsync /etc/inetd.conf
rsync   stream  tcp     nowait  root   /usr/bin/rsync rsyncd --daemon
# grep rsync /etc/services
rsync           873/tcp

Then on the backup side, you can configure a fakeroot environment if necessary, then run:

# rsync -az --delete rsync://prod_server/prd_data /path/to/fakeroot
  • I guess with this comes a different question: Do you push backups out from the production server or pull them in from the backup server? To me, pushing them out makes more sense, so there isn't an automated remote connection into your production server. – Craig Younkins Jul 29 '09 at 4:25
  • The above setup is pulled from the backup server. To reverse the process, setup an rsync server on the backup system that allows writes only from the production server. – baumgart Jul 29 '09 at 17:05

My solution to not opening servers to root access when needed for rsync to operate and maintain all ownerships/privs is to both push from the live server(s) and pull to the backups, using an intermediate staging area on an extra machine.

Done this way, both the backup and live servers have SSH access and root privileges on the staging area, but never need to communicate at all directly so do not need privileged access to each other. And the staging server does not need any access to make connections to either live or backup machines.

This adds a little complication, but means you do not need to enable logins to privileged accounts via SSH at either end. It also adds a little extra useful security through the separation - if you make sure that the live and backup servers do not share any credentials then if someone manages to hack into (or just obtain/guess a password for) a privileged account on either the live or the backup servers they can't then use access to one to easily gain access to the other.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.