rsync - Jan 2007 - Replicating a tree with root permissions

We have a large (20Gb, 250000 files) tree which needs to replicate across our
WAN on a regular basis.  We have been using a wrapper script around rsync to do
this; the wrapper script runs setuid-root on a Solaris 8 server.  However, we
have on-going problems with files whose permissions don't replicate
correctly.  These file permissions are the REAL problem; if the permissions
aren't correct, the tree isn't useful.

Current rsync command-line:

rsync -e rsh --stats --delete -avz --ignore-errors --blocking-io
--exclude-from="exclude.list" --rsync-path="rsync_path"
remote_host:/my/source/dir /my/source

The most recent failure involves files which are owned by root; if I run the
setuid wrapper script from a user account, the permissions are not updated; if I
run the setuid script as root (and change the command line to add
"user@remote_host), then the permissions get updated.

Note that there are other files in the tree which are owned by root which
replicate correctly!!!

Notes:
 - rsync v2.6.6 at both sites.
 - Solaris 8 at both sites.
 - The entire WAN is one Solaris NIS domain, so the user names / uid's match
on both sides.
 - We are NOT able to leave the rsync daemon running at either end. . . .:-(
 - The tree contains files belonging to MANY different users, including root. 
It also includes setuid scripts which SHOULD be replicated with the setuid bits
intact.
 - The entire tree is NFS mounted at both sites from a NetApp file server.
 - If I run with "-n -i", it clearly shows that the file permissions
will not be updated when a regular user starts the script, but WILL be updated
if the script is run by root.

What is the most reliable way to replicate this tree and retain the permissions
on the "target" site?

Thanks.

Dan


-- 
The information contained in this communication and any attachments is
confidential
and may be privileged, and is for the sole use of the intended recipient(s). Any
unauthorized review, use, disclosure or distribution is prohibited. If you are
not
the intended recipient, please notify the sender immediately by replying to this
message and destroy all copies of this message and any attachments. ASML is
neither
liable for the proper and complete transmission of the information contained in
this
communication, nor for any delay in its receipt.

On Thu 18 Jan 2007, Daniel Rawson wrote:
> We have a large (20Gb, 250000 files) tree which needs to replicate across 
> our WAN on a regular basis.  We have been using a wrapper script around 
> rsync to do this; the wrapper script runs setuid-root on a Solaris 8 
In my experience, on most systems setuid scripts aren't executed setuid
bye the kernel, because it's inherently insecure. Some sudo setup is
probably more dependable.
> server.  However, we have on-going problems with files whose permissions 
> don't replicate correctly.  These file permissions are the REAL
problem; if
> the permissions aren't correct, the tree isn't useful.  
> Current rsync command-line:
> 
> rsync -e rsh --stats --delete -avz --ignore-errors --blocking-io 
> --exclude-from="exclude.list" --rsync-path="rsync_path"
> remote_host:/my/source/dir /my/source
> 
> The most recent failure involves files which are owned by root; if I run 
> the setuid wrapper script from a user account, the permissions are not 
> updated; if I run the setuid script as root (and change the command line to
> add "user@remote_host), then the permissions get updated.
> 
> Note that there are other files in the tree which are owned by root which 
> replicate correctly!!!
> 
> Notes:
> - rsync v2.6.6 at both sites.
> - Solaris 8 at both sites.
> - The entire WAN is one Solaris NIS domain, so the user names / uid's
match
> on both sides.
> - We are NOT able to leave the rsync daemon running at either end. . . .:-(
> - The tree contains files belonging to MANY different users, including 
> root.  It also includes setuid scripts which SHOULD be replicated with the 
> setuid bits intact.
> - The entire tree is NFS mounted at both sites from a NetApp file server.
>From two distinct NetApp file servers, I assume?
Is the NFS filesystem mounted with no_root_squash or whatever the option
on Solaris might be, so that root can actually access all files as root?
Usually root it mapped to "nobody" over NFS...

It may help if you give some real (not obfuscated) examples, commands
with the output, and stat (or ls -l) output of the concerned files.


Paul Slootman