John Hedges wrote:
>I've just stumbled upon rsyncrypto, it seems to do just what I need
>except for one thing.
>I want to use rsync to backup servers but don't want to enable root
>ssh. It would be useful if rsyncrypto could store file
>ownership/permissions in the encrypted files and make the encrypted
>files 0600 and owned by an arbitrary user - say backup.
Storing permissions inside the encrypted files is planned, but will take
a little while to implement (mostly because I got Hodgkin's disease, and
will take a few months to return to full capacity work).
The permissions of the encrypted files are governed, if memory serves me
right, by the umask. Do whatever you like with it :-)
I doubt I'll add a flag to change the ownership of the files during
backup. You are free to run "chown -R" on the directory after rsyncrypto
> That way I can
>rsync using the user 'backup' with minimal ssh privileges. The decrypt
>could then restore the original permissions.
Yes, it is also planned that the full permissions (including ownership
and, at some later date, also ACL and filesystem attributes) will be
restored by rsyncrypto. In fact, this feature is the only one holding me
from announcing "rsyncrypto" production, as it will require changing the
encrypted file structure, and I would like to do several necessary
changes at once here.
> Perhaps this is already
>possible or maybe you know of a simple workaround.
Aside from performing tar to stdout, and piping that to rsyncrypto, I'm
afraid I know of no workaround yet :-(
>I've also noticed that files' executable permissions are lost in the
>encrypt/decrypt cycle - is this intentional?
No, it's a natural byproduct of the above missing feature.
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html