Problems with rsync server over ssh client

Jeremy Hansen jeremy at
Thu Feb 3 23:49:48 GMT 2005

On 2/3/05 2:56 PM, "Wayne Davison" <wayned at> wrote:

> On Thu, Feb 03, 2005 at 02:01:28PM -0800, Jeremy Hansen wrote:
>> use --rsh="ssh -l username", that the rsync server is ignore my
>> rsyncd.conf uid and gid directives.
> Correct.  Normal users don't have unix permissions to change to another
> user, so rsync assumes that if you're not root (UID 0), you can't
> setuid().
> If you're trying to limit what remote hosts can connect, the best
> solution is probably to go back to using a daemon and adding a "hosts
> allow" value of "" so that the only connections it allows are
> from localhost.  Then, your remote users would use ssh to tunnel into
> the machine and connect:
>   ssh -fN -L 8873:localhost:873 -l joeuser filedrop
>   rsync -av foo.txt --port 8873 localhost::repository/
> (If you connect via ssh1, dump the -N option and specify a "sleep 30"
> command.)  All the users on the same remote machine can make use of the
> port-8873 connection to filedrop's port 873.
> If instead you were trying to provide different permissions to different
> users based on who they logged in as via ssh, you'll need to come up
> with something custom for that.  For instance, if you created a wrapper
> program that would only execute a hard-wired rsync command based on the
> who the current user was, you could set the "setuid" bit on the
> executable, and it would then run rsync with root permissions.  Whether
> that would be secure enough for your system depends on how you feel
> about setuid-bit programs and also on how well you code up the exec
> logic (making sure that it can't try to run arbitrary programs, for
> instance).

It sounds as if I need some kind of wrapper.  Host based filtering isn't my
issue.  I need to allow users to upload files to other users and I need
those uploaded files to have the correct ownership of whoever the files are
being given to.  I understand now that using the --rsh="ssh -l user" command
just spawns an rsync session as whatever "-l user" is, therefore the
degraded permissions.

I see from the archives that someone wrote an ldap patch, which seems as if
it would work well for my situation.


> ..wayne..

More information about the rsync mailing list