4

I would like to perform incremental backups (for the entire filesystem) from a machine. rsync does this quite will, however I would like to also preserve file ownership - meaning, make it possible to restore it.

Is this possible to do without running rsync as root on the target machine (storing the backups)?

Some ideas...

  • Is there a way to mount a filesystem (FUSE?) in such a way as to allow chown for a non-root user? (I guess it would probably need to be noexec to forbid elevation.)
  • Some way to store and restore the ownership in metadata files instead of the filesystem itself?
  • tar can store file ownership, though getting it to work with rsync or incremental backups would be a bit more involved. It would also be nice to be able to browse the backups like a regular filesystem.
  • Perhaps some kind of fake root environment? A virtual machine would work, but would be nice to avoid the associated maintenance and performance overhead.
12

As stated in the other answers, to directly preserve ownership information you need root access to the destination machine.

However, you had at least two workarounds to avoid root access while preserving ownership:

  1. use the --fake-super rsync option. From the man page:

When this option is enabled, rsync simulates super-user activities by saving/restoring the privileged attributes via special extended attributes that are attached to each file (as needed)

This means that ownership is not directly preserved in classical Unix style, rather ownership information is stored inside a special extended attribute (ie: a sort of "tag" attached to the file). When restoring, rsync can use this EA/tag to correctly reconstruct the original file owner.

  1. do not let rsync preserve ownership information, rather preserve them using the getfacl utility. For example, issuing getfacl -R MNTPOINT > acls.txt you effectively save ownership (and ACL) info in a text file which can be later used to restore such information using the setfacl --restore command.
  • Wow, the --fake-super option is exactly what I needed. Thank you! – Vladimir Panteleev Feb 12 '16 at 17:04
2

If I were you, I would put the backups on a volume in a Docker container. This way, you can put good limits on it and avoid security risks but still run it as root so it does what it needs to do.

  • I don't know why this was downvoted. But would this work, considering that - AIUI - containers require mapping a specific set of UIDs, and forbid operations on UIDs outside the mapped set? – Vladimir Panteleev Feb 12 '16 at 10:27
1

Rather than copying all your files one-by-one like rsync does, you should consider putting the files in some kind of "container" that lets you pack up all the files, transport them around, and never lose any metadata.

Have you considered "tar"? I know that tar is the antithesis of rsync: it isn't incremental, it doesn't transport the data anywhere, etc.

However it is really good at preserving ownership, permissions, ACLs, modification times, and such. You can make a tar file, copy it to a machine that doesn't even understand the Unix way of doing file permissions (i.e. Windows, TOPS-20, VAX/VMS), then copy it back to a Unix host, untar it, and you get all the permissions, etc. that it originally had.

There is a FUSE filesystem that will mount (read-only) tar files.

Of course, you lose the incremental copies and other features that make rsync such an excellent tool. However, the Unix world used tar for 20+ years before rsync was invented and it works really well for certain situations.

0

Well, basically you already know the answer: No you just cannot.

That's the basics of unix and the likes' filesystems permisions (which seems to be your environment): you cannot do much on files on which you don't have the rights or ownership. So if you want to copy "the whole filesystem", which includes a lot of root files, you have to be super user on both source and destination systems.

I stated you knew the answer because you already suggested using other tools like tar, virtual machines and the like, which then is not "preserve with rsync". Hopefully, there is no easy trick to fool the filesystem, otherwise we would not have even a basic security level.

On your destination filesystem, rsync can receive tar files with detailed permissions "hidden" inside, but then
- you still have to be root to untar them with the corresponding permissions – given they include root files,
- rsync is not doing anything incremental with such tar balls.
On the other hand, if you prepare tar files of your config files, it won't be heavy and you can send these on any backup system, via rsync or FTP.

And separately, if you only save your users' data and they pertain to a common group (like the FTP users' group, for instance), which is obviously not root, you can rsync the whole set of folders with that group id, not being root on either system.

If you go that way, make sure that any user and group you use exists and is equal (name/number) on both systems or you may get surprises.

Of course, the whole thing does not look like a professional solution. And you will also need to prepare for emergency restore procedure and ways to select the correct version you wish to restore, etc..

-1

Obviously to get the "root" files from the destination, you need root access. However, there are many ways to screw your system.

1) You could allow rsync to use sudo without password 2) You could use setuid to rsync so that it can access root files, while the backup orchestrator is a normal user rather than the root. 3) use rssh to limit the security risks of all the above

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.