Using rsync to mirror directories where root owns file, using non-root user to initiate session

Kevin Korb kmk at
Wed Jun 20 21:40:57 MDT 2012

Hash: SHA1

On 06/20/12 21:53, Karl O. Pinc wrote:
> On 06/20/2012 05:29:09 PM, Kevin Korb wrote:
> Along these lines...
> Somehow or another you need root access on the remote side in order
> to properly set permissions. You can use ssh public keys to invoke
> a rsync daemon. In /root/.ssh/authorized_keys you put the public
> key on a line like:

Not permissions, ownership.  Only root can create or modify files with
arbitrary ownership and only root can change the ownership of a file.
 This is the basic *nix file security model.  It has nothing to do
with rsync other than rsync being constrained to it.

> no-pty,command="rsync --server --daemon ." ssh-dss ....
> This allows someone with the private key on the local end to run a
> remote rsync server as root.  To invoke on the client side see the
> rsync man page section: USING RSYNC-DAEMON FEATURES VIA A

This is what rrsync can accomplish.  It is designed to allow rsync
access only to a specific directory even when running as root.

> rsync -av -e "ssh -l ssh-user" rsync-user at host::module /dest

Now you are talking rsyncd over ssh. Still as root.  The benefit is
minimal at best.

> In addition to no-pty you may also wish to use no-agent-forwarding,
> no-port-forwarding, no-user-rc, no-X11-forwarding and, possibly,
> from="pattern-list".


> The problem with the above is that the remote end does run as root,
> so you're relying on your remote rsync config to keep the user from
> doing bad things on the remote end.
> See also the rrsync script in the rsync examples directory.  rrsync
> can be used as the command= value instead of the above rsync
> command.

Yes, see rrsync.  It is in the support directory of the rsync source

Also see --fake-super which allows you to store super user features
like file ownership in the file extended attributes instead of in the
filesystem.  Therefore root isn't required.

>> On 06/20/12 18:26, PEOPLES, MICHAEL P wrote:
>>> I have spent a day researching and attempting to debug this
>>> issue. I am hoping someone can tell me how (or disabuse me of
>>> the delusion that it's possible) to do the following:
>>> - Mirror the contents of a directory on one server to a remote 
>>> server where there are diverse ownership and permissions
>>> - File and directory ownership on both the source and
>>> destination servers would normally prevent the user account
>>> initiating the rsync session from accessing, modifying, or
>>> changing attributes of the files and directories in question
>>> - Session authentication of the initiating user on the remote 
>>> server must be by public key
>>> - No root logins are permitted on either server
>>> I can successfully transfer the files with the user account,
>>> but if the files have ownership attributes that need to be set
>>> on the remote (destination) server, using the --owner, --group,
>>> and/or --perms options produces errors indicating the
>>> "Operation is not permitted".  When logged into the remote
>>> server as the user, I still cannot modify the attributes, only
>>> root (super user) can do this.  The "--super" command line
>>> option appears to have no effect.
>>> Both servers are Red Hat Linux.  I am using rsync 3.0.9.
>>> The only way I can conceive of doing this would be to record
>>> the file attributes, transfer the files (along with a record of
>>> their attributes), then run a script using sudo that would move
>>> the files into their final location and set the attributes.
>>> This, however, would seem to defeat much of the purpose of
>>> rsync.
>>> The manuals suggest there is a way to invoke super user 
>>> functionality when contacting a daemon instance, but I could
>>> not get this to work.  However, this appears to require
>>> contacting an rsync daemon started by root.  Attempting to
>>> perform the rsync, while simultaneously using the public key,
>>> which can only be used when "ssh" is invoked, seems to exclude
>>> the use of the daemon on the remote side, effectively running
>>> the entire rsync session as the user without elevated
>>> privileges.
>>> In short, I want to copy files from one server to another, and
>>> have all ownership and permissions preserved (including root),
>>> using rsync to perform "privileged" operations to set file
>>> attributes properly and a public key to authenticate the user.
>>> Thanks.
>>> Michael Peoples (mp4783) Senior Systems Manager AT&T - ATTSI 
>>> Office/Cell:  614-886-0923 
>>> mpeoples at<mailto:mpeoples at>
>>> This e-mail and any files transmitted with it are AT&T
>>> property, are confidential, and are intended solely for the use
>>> of the individual or entity to whom this email is addressed. If
>>> you are not one of the named recipient(s) or otherwise have
>>> reason to believe that you have received this message in error,
>>> please notify the sender and delete this message immediately
>>> from your computer. Any other use, retention, dissemination,
>>> forwarding, printing, or copying of this e-mail is strictly
>>> prohibited."
>> -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,- 
>> *~'`^`'~*-,._.,-*~ Kevin Korb			Phone:    (407) 252-6853 Systems
>> Administrator		Internet: FutureQuest, Inc.		Kevin at
>> (work) Orlando, Florida		kmk at (personal) Web page:
>> PGP public key available on web site. 
>> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,- 
>> *~'`^`'~*-,._.,-*~
> Karl <kop at> Free Software:  "You don't pay back, you pay
> forward." -- Robert A. Heinlein

- -- 
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at  (work)
	Orlando, Florida		kmk at (personal)
	Web page:
	PGP public key available on web site.
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the rsync mailing list