On Fri, 2009-10-30 at 12:16 -0400, JESSE CARROLL wrote:> Forgive me if the answer is obvious but I've googled and searched the
> archives but I can't seem to find a good solution.
>
> Scenario on a Solaris system:
>
> ls -ld /foo
> drwxrwxrwx 2 user1 other 512 Oct 30 16:05 /foo
>
> ls -l /foo/*
> total 0
> -rw-r--r-- 1 user1 other 10 Oct 30 16:05 /foo/file_a
> -rw-r--r-- 1 user2 staff 30 Oct 30 16:05 /foo/file_b
>
> (Yes I know wide open directories are evil, but the application folks
> do strange things.)
>
> If I use rsync as user1 all the files on the destination server are
> owned by user1. I.E.
>
> ls -l /foo/*
> total 0
> -rw-r--r-- 1 user1 other 10 Oct 30 16:05 /foo/file_a
> -rw-r--r-- 1 user1 other 30 Oct 30 16:05 /foo/file_b
>
> I'm trying to avoid using rsynd as we're paranoid about security.
(We
> change root password on a regular basis. The solutions indicate that I
> may have to change the secrets file each time.)
>
> Any suggestions on preserving the file ownership in this case?
Whoops, it would help if I read your whole message before replying. In
order to have the power to set the destination ownership to match the
source ownership, the receiving rsync must run as root; this requirement
is imposed by the OS. You'll need to use ssh as root or an rsync daemon
running as root. If you want to piggyback on the existing
well-maintained root password but like some of the extra protections of
an rsync daemon, you can use an ssh-invoked single-use daemon, as
described in the "USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL
CONNECTION" section of the rsync man page.
--
Matt