rsync - Jan 2003 - Not preserving permissions really preserves some

This appears to be a feature :-)

I'm running rsync 2.5.5 on Solaris 8, and testing transferring
files between two boxes with permission preservation turned *off*.

I have three files:

700 with permissions 700
770 with permissions 770
777 with permissions 770

The umask for the target system is set to: 007
[I have checked this via prints from the rsync code]

When the files get transferred, the permissions are:

700 -> permission 700
770 -> permission 770
777 -> permission 770

This retains the permissions from the group part of the file 700.
That is, even though my umask wants the group set, it doesn't
get set.

Why this is a problem for me:

I don't trust the source system to get the permissions correct
(it's a windows box running cygwin), and I want to force a set
of permissions so the process using the synched directory will
be able to access it (through group permissions).

Suggested solution:

I don't think changing the way permissions are created would be
that backward-compatible, so maybe a new option?

Create an option: --ignore-permissions

in receive_file_entry(), in filelist.c


========== code block ===================if (!preserve_perms) {
    extern int orig_umask;
    /* set an appropriate set of permissions based on original
       permissions and umask. This emulates what GNU cp does */

       file->mode &= ~orig_umask;  <-- change this to line below

       file->mode = ((ignore_perms?0:0666) | file->mode) &
~orig_umask;
}

I used 0666 for the mask to pick up the execute bit (otherwise might
screw up creating directories we can go down).


I would be interested in any feedback on this problem from the maintainers.
If there is any agreement on how it might be addressed and included in a
new version, then I am happy to create all of the patch files and test it
for submission to a maintainer.

If any replies to the list could also cc my reply address, that would
be appreciated.

Regards,
    - Tim





The information contained in this e-mail communication may be confidential.
You should only read, disclose, re-transmit,copy, distribute, act in
reliance on or commercialise the information if you are authorised to do
so. If you are not the intended recipient of this e-mail communication,
please immediately notify us by e-mail to postmaster@mlc.com.au, or reply
by e-mail direct to the sender and then destroy any electronic and paper
copy of this message.

Any views expressed in this e-mail communication are those of the
individual sender, except where the sender specifically states them to be
the views of a member of the National Australia Bank Group of companies.

The National Australia Bank Group of companies does not represent, warrant
or guarantee that the integrity of this communication has been maintained
nor that the communication is free of errors, virus or interference.

I would object to that because it would change existing functionality
(emulating GNU cp) and isn't general enough.  We've discussed a possible
general manipulation of permissions; see
    http://lists.samba.org/pipermail/rsync/2002-March/006477.html

Alternatively, you could process the output of the -v option and run
xargs chmod on all files that have been touched.

- Dave Dykstra

On Thu, Jan 02, 2003 at 12:47:18PM +1100, tim_smithers@mlc.com.au
wrote:
> 
> This appears to be a feature :-)
> 
> I'm running rsync 2.5.5 on Solaris 8, and testing transferring
> files between two boxes with permission preservation turned *off*.
> 
> I have three files:
> 
> 700 with permissions 700
> 770 with permissions 770
> 777 with permissions 770
> 
> The umask for the target system is set to: 007
> [I have checked this via prints from the rsync code]
> 
> When the files get transferred, the permissions are:
> 
> 700 -> permission 700
> 770 -> permission 770
> 777 -> permission 770
> 
> This retains the permissions from the group part of the file 700.
> That is, even though my umask wants the group set, it doesn't
> get set.
> 
> Why this is a problem for me:
> 
> I don't trust the source system to get the permissions correct
> (it's a windows box running cygwin), and I want to force a set
> of permissions so the process using the synched directory will
> be able to access it (through group permissions).
> 
> Suggested solution:
> 
> I don't think changing the way permissions are created would be
> that backward-compatible, so maybe a new option?
> 
> Create an option: --ignore-permissions
> 
> in receive_file_entry(), in filelist.c
> 
> 
> ========== code block ===================> if (!preserve_perms) {
>     extern int orig_umask;
>     /* set an appropriate set of permissions based on original
>        permissions and umask. This emulates what GNU cp does */
> 
>        file->mode &= ~orig_umask;  <-- change this to line below
> 
>        file->mode = ((ignore_perms?0:0666) | file->mode) &
~orig_umask;
> }
> 
> I used 0666 for the mask to pick up the execute bit (otherwise might
> screw up creating directories we can go down).
> 
> 
> I would be interested in any feedback on this problem from the maintainers.
> If there is any agreement on how it might be addressed and included in a
> new version, then I am happy to create all of the patch files and test it
> for submission to a maintainer.
> 
> If any replies to the list could also cc my reply address, that would
> be appreciated.
> 
> Regards,
>     - Tim
> 
> 
> 
> 
> 
> The information contained in this e-mail communication may be confidential.
> You should only read, disclose, re-transmit,copy, distribute, act in
> reliance on or commercialise the information if you are authorised to do
> so. If you are not the intended recipient of this e-mail communication,
> please immediately notify us by e-mail to postmaster@mlc.com.au, or reply
> by e-mail direct to the sender and then destroy any electronic and paper
> copy of this message.
> 
> Any views expressed in this e-mail communication are those of the
> individual sender, except where the sender specifically states them to be
> the views of a member of the National Australia Bank Group of companies.
> 
> The National Australia Bank Group of companies does not represent, warrant
> or guarantee that the integrity of this communication has been maintained
> nor that the communication is free of errors, virus or interference.
> 
> -- 
> To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Thanks for the reply.

I did see this on the to-do list, and thought that it might
be a preferable solution (just a bit more work).
It would be messy to do the xargs stuff as I am running rsync
over ssh with restricted commands based upon keys :-)

Questions:
   1. Is the proposed solution in the todo (--chmod) agreed?
   2. Is anyone actively working on it?
   3. If I wrote the patch to support the --chmod as outlined
      in the todo file, would someone apply it (assuming my
      code was okay ;-) ?
   4. Should the patch be applied to the "head", or should it
      be against the latest release version?

Thanks in advance.
Regards,
     - Tim

>To:    tim_smithers@mlc.com.au
>cc:    rsync@lists.samba.org
>Subject:       Re: Not preserving permissions really preserves some
>
>I would object to that because it would change existing functionality
>(emulating GNU cp) and isn't general enough.  We've discussed a
possible
>general manipulation of permissions; see
>    http://lists.samba.org/pipermail/rsync/2002-March/006477.html
>
>Alternatively, you could process the output of the -v option and run
>xargs chmod on all files that have been touched.
>
>- Dave Dykstra
>
>On Thu, Jan 02, 2003 at 12:47:18PM +1100, tim_smithers@mlc.com.au wrote:
>>
>> This appears to be a feature :-)
>>
>> I'm running rsync 2.5.5 on Solaris 8, and testing transferring
>> files between two boxes with permission preservation turned *off*.
>>
>> I have three files:
>>
>> 700 with permissions 700
>> 770 with permissions 770
>> 777 with permissions 770
>>
>> The umask for the target system is set to: 007
>> [I have checked this via prints from the rsync code]
>>
>> When the files get transferred, the permissions are:
>>
>> 700 -> permission 700
>> 770 -> permission 770
>> 777 -> permission 770
>>
>> This retains the permissions from the group part of the file 700.
>> That is, even though my umask wants the group set, it doesn't
>> get set.
>>
>> Why this is a problem for me:
>>
>> I don't trust the source system to get the permissions correct
>> (it's a windows box running cygwin), and I want to force a set
>> of permissions so the process using the synched directory will
>> be able to access it (through group permissions).
>>
>> Suggested solution:
>>
>> I don't think changing the way permissions are created would be
>> that backward-compatible, so maybe a new option?
>>
>> Create an option: --ignore-permissions
>>
>> in receive_file_entry(), in filelist.c
>>
>>
>> ========== code block ===================>> if (!preserve_perms)
{
>>     extern int orig_umask;
>>     /* set an appropriate set of permissions based on original
>>        permissions and umask. This emulates what GNU cp does */
>>
>>        file->mode &= ~orig_umask;  <-- change this to line
below
>>
>>        file->mode = ((ignore_perms?0:0666) | file->mode) &
~orig_umask;
>> }
>>
>> I used 0666 for the mask to pick up the execute bit (otherwise might
>> screw up creating directories we can go down).
>>
>>
>> I would be interested in any feedback on this problem from the
maintainers.
>> If there is any agreement on how it might be addressed and included in
a
>> new version, then I am happy to create all of the patch files and test
it
>> for submission to a maintainer.
>>
>> If any replies to the list could also cc my reply address, that would
>> be appreciated.
>>
>> Regards,
>>     - Tim
>>

On Wed, Jan 08, 2003 at 03:08:38PM +1100, tim_smithers@mlc.com.au
wrote:
> 
> 
> Thanks for the reply.
> 
> I did see this on the to-do list, and thought that it might
> be a preferable solution (just a bit more work).
> It would be messy to do the xargs stuff as I am running rsync
> over ssh with restricted commands based upon keys :-)
> 
> Questions:
>    1. Is the proposed solution in the todo (--chmod) agreed?
Yes.

>    2. Is anyone actively working on it?
No.

>    3. If I wrote the patch to support the --chmod as outlined
>       in the todo file, would someone apply it (assuming my
>       code was okay ;-) ?
Yes, although probably not in the very next release, probably in 2.6.0,
unless the changes ended up being very isolated and we could clearly see
there was very little risk in breaking something else.

>    4. Should the patch be applied to the "head", or should it
>       be against the latest release version?
To the CVS "head".

- Dave