Re: [Possible SPAM]:Re: Patch to not modify files in place unless

This is a discussion on Re: [Possible SPAM]:Re: Patch to not modify files in place unless within the Rsync forums, part of the Networking and Network Related category; This is a multi-part message in MIME format. --===============0601194246== Content-Type: multipart/alternative; boundary="------------050408040605010008010605" This is ...

		Usenet Forums > Networking and Network Related > Rsync
Re: [Possible SPAM]:Re: Patch to not modify files in place unless

LinkBack

Thread Tools

Display Modes

#1 (permalink)

4 Days Ago

Carl E. Thompson

Posts: n/a

Re: [Possible SPAM]:Re: Patch to not modify files in place unless

This is a multi-part message in MIME format.
--===============0601194246==
Content-Type: multipart/alternative;
boundary="------------050408040605010008010605"

This is a multi-part message in MIME format.
--------------050408040605010008010605
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Wayne Davison wrote:
> On Wed, May 07, 2008 at 06:25:36PM -0700, Carl E. Thompson wrote:
>
>> This patch causes rsync to honor the absence of the "--inplace" option
>> for permission, owner and group changes.
>>
>
> Unfortunately, that's not what the --inplace option is for. Its purpose
> is to control how data updates occur, not attribute updates. If I make
> rsync break hard-links to make attribute updates, it will need to be a
> new option, as is done in Matt's patch.
>
OK, but it seems a little counter-intuitive to say that the "--inplace"
option controls some in place file modifications but not others. This
also appears to be counter to the man page description of the
"--inplace" option which states

This causes rsync not to create a new copy of the file and then move
it into place.

This implies of course that if the "--inplace" option is *not* given
then rsync *will* "create a new copy of the file and then move it into
place." What you seem to be saying is that really isn't true. If this is
the desired behavior of "--inplace" then the documentation is misleading
at best.

I guess what I'm saying that the current behavior seems to be counter to
the documentation, is not what a user of a tool like this would expect
and leads to significant well-known security vulnerabilities in common
use. On the other hand no one has yet been able to point out any real
world use case where applying this fix would lead to incorrect results.

So to me this would seem to fall in the category of a bug or security fix.
> ...
>
> ..wayne..
>

Thank you,
Carl Thompson

--------------050408040605010008010605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content=3D"text/html;charset=3DUTF-8" http-equiv=3D"Content-Type"=
>
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
 
 
Wayne Davison wrote:
<blockquote cite=3D"mid:20080508031418.GA26955@blorf.net" type=3D"cite">
<pre wrap=3D"">On Wed, May 07, 2008 at 06:25:36PM -0700, Carl E. Thomps=
on wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">This patch causes rsync to honor the absence of the "-=
-inplace" option
for permission, owner and group changes.
</pre>
</blockquote>
<pre wrap=3D"">
Unfortunately, that's not what the --inplace option is for. Its purpose
is to control how data updates occur, not attribute updates. If I make
rsync break hard-links to make attribute updates, it will need to be a
new option, as is done in Matt's patch.
</pre>
</blockquote>
OK, but it seems a little counter-intuitive to say that the "--inplace"
option controls some in place file modifications but not others. This
also appears to be counter to the man page description of the
"--inplace" option which states 
 
<tt>=C2=A0=C2=A0=C2=A0 This causes rsync not to create a new copy of the =
file
and then move it into place.</tt> 
 
This implies of course that if the "--inplace" option is not
given then rsync will "create a new copy of the file and then
move it into place." What you seem to be saying is that really isn't
true. If this is the desired behavior of "--inplace" then the
documentation is misleading at best. 
 
I guess what I'm saying that the current behavior seems to be counter
to the documentation, is not what a user of a tool like this would
expect and leads to significant well-known security vulnerabilities in
common use. On the other hand no one has yet been able to point out any
real world use case where applying this fix would lead to incorrect
results. 
 
So to me this would seem to fall in the category of a bug=C2=A0 or securi=
ty
fix. 
<blockquote cite=3D"mid:20080508031418.GA26955@blorf.net" type=3D"cite">
<pre wrap=3D"">...

...wayne..
</pre>
</blockquote>
 
Thank you, 
Carl Thompson 
 
</body>
</html>

--------------050408040605010008010605--

--===============0601194246==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
--===============0601194246==--

« Previous Thread | Next Thread »

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Posting Rules
You may not post new threads You may not post replies You may not post attachments You may not edit your posts vB code is On Smilies are Off [IMG] code is Off HTML code is Off Trackbacks are On Pingbacks are On Refbacks are On

All times are GMT +1. The time now is 07:03 PM.