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

Karl O. Pinc kop at meme.com
Wed Jun 20 19:53:13 MDT 2012


On 06/20/2012 05:29:09 PM, Kevin Korb wrote:
> http://www.sanitarium.net/rsyncfaq/#sudo

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:

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 REMOTE-SHELL CONNECTION

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

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.


> 
> 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 att.com<mailto:mpeoples at att.com>
> >
> > 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 FutureQuest.net  (work)
> 	Orlando, Florida		kmk at sanitarium.net (personal)
> 	Web page:			http://www.sanitarium.net/
> 	PGP public key available on web site.
> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-
> *~'`^`'~*-,._.,-*~
> 




Karl <kop at meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein



More information about the rsync mailing list