cannot rsync when source directory lacks write permission

[Steven Levine]

In
<64FAB8215D47A944ABDF7DE50A3406A219C2DACAC4 at ESESSCMS0353.eemea.ericsson.se>,
on 08/10/12
   at 09:27 AM, András Porjesz <andras.porjesz at ericsson.com> said:

Hi András,

We may have to agree to disagree on some of this...

>Of course, the destination side must have enough rights to achieve what I
>need, and an rsyncd running as root:root surely have all the necessary
>rights. So using --perms with this daemon must have been sufficient.

No, it's not the way it works and not the way I would want it to work.  I
do not want the server to automatically assume that the client can be
trusted to do the right thing with data that is owned by the server.

The fact that the rsync daemon is running as root is irrelevant.  As you
know from your many years of *ix experience, it is normal for a
application running as root to use setuid to limit the rights it has.  In
my experience, it is typical for a server to do setuid nobody, unless
instructed otherwise.

>But not, it is simply not true, because the daemon has a built-in
>"assumption" which overkills it. I know rsync sends its command line
>parameters to the daemon, so rsyncd could have been able to handle the
>case, but instead of recognizing the flag it simply makes that
>assumption.

The assumption it makes is that the rsyncd.conf is correct when there is a
choice to be made.  This make absolutely good sense to me since in my
world, the server knows what's best and the client is less trusted.

>1. use exactly the same options on both sides

This already happens.  What does not happen is that the server does not
automatically run as root.

>2. specify which attributes to transfer (keep) and which ones to set
>explicitly (including permissions, ownership, time and probably acl also)

This already happens.  It is the client's responsibility to do this.  The
server will do it's best to fulfill the request.  Failures can and will
occur it the client asks the server to do something that exceeds its
rights or is something the platform does not support.  For example, I
maintain an rsync port for a platform that does not support hard links. 
There's a whole set of client options that generate errors if the client
requests them.

>4. define a precedence (like: source filesystem, sender config, receiver
>config, receiver user rights, defaults) 5. describe actions taken in case
>of insufficient rights

Most of this is already in place.  If the server has insufficient rights
the request will fail in some way and rsync will proceed, depending on
options such as --ignore-errors.

>(just another example: client side -E, server side incoming chmod u+x,g-x
>and outgoing chmod u+x,g-x: what is the expected result when sending or
>receiving files?)

As the man page says

<snip>
o      To  make  a  file executable, rsync turns on
       each x permission that has a corresponding r
       permission enabled.

If --perms is enabled, this option is ignored.
</snip>

>Using aliases these can be mapped to the actual flags - for backward
>compatibility

Huh?

Steven

-- 
----------------------------------------------------------------------
"Steven Levine" <steve53 at earthlink.net>  eCS/Warp/DIY etc.
www.scoug.com www.ecomstation.com
----------------------------------------------------------------------