Re: [RFC PATCH] Add SHA1 support

2020-03-17 Thread Dimitrios Apostolou via rsync

On Tuesday, March 17, 2020 9:17:09 PM CET, Sebastian Andrzej Siewior wrote:

On 2020-03-17 00:03:03 [+0100], Dimitrios Apostolou via rsync wrote:

On Thursday, February 20, 2020 10:34:53 PM CET, Sebastian Andrzej Siewior
via rsync wrote:


I'm still not sure if rsync requires a cryptographic hash _or_ if a
strong hash like xxHash64 would be just fine for the job.


I'm fairly sure the hash should *not* be easy to spoof, so I'd say a
cryptographic hash is needed.

As an example, if a file is replaced by a file of the same size and same
hash,
rsync (if -c is in use) will consider the file is the same, and avoid
copying it.


correct. The same goes for currently used md5 which has known collision
attacks. So if you intend to spoo it, you can manufacture the same hash
for two different files for both algorithms. 


This was not the case in 2008 when rsync 3.0.0 came out defaulting to MD5.
I still think you need a cryptographic hash, even though I am not sure
of how strict the requirement is. MD4 was replaced by MD5 in rsync, despite 
MD4

being 2x faster. I would guess it was replaced because of its weaknesses.


Dimitris


--
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


Re: [RFC PATCH] Add SHA1 support

2020-03-16 Thread Dimitrios Apostolou via rsync
On Thursday, February 20, 2020 10:34:53 PM CET, Sebastian Andrzej Siewior 
via rsync wrote:


I'm still not sure if rsync requires a cryptographic hash _or_ if a
strong hash like xxHash64 would be just fine for the job.


I'm fairly sure the hash should *not* be easy to spoof, so I'd say a 
cryptographic hash is needed.


As an example, if a file is replaced by a file of the same size and same 
hash,
rsync (if -c is in use) will consider the file is the same, and avoid 
copying it.



Dimitris


--
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


Re: Would you expect --perms -M--fake-super to set the file mode to the original one?

2020-03-16 Thread Dimitrios Apostolou via rsync

According to --help:

 --fake-superstore/recover privileged attrs using xattrs

So I would assume which mode it uses when it reads the file,
depends on whether this option is on or off.


On Monday, March 16, 2020 9:09:36 PM CET, Kevin Korb via rsync wrote:

I don't believe it is possible.  I think the misunderstanding stems from
the fact that the permissions are even stored in the xattr.  They don't
need to be there but they may as well be.  They don't take much space.
The real question would be when rsync reads the file to restore it and
the file perms are different than the ones in the xattr which set does
it use?

On 3/16/20 10:01 AM, Dimitrios Apostolou via rsync wrote:

Thanks. This is a bit counter-intuitive to me. So how would you tell
rsync to store the original permissions in the xattr, but do not touch
the real file mode?

On Thursday, March 12, 2020 6:26:18 PM CET, Kevin Korb via 
rsync wrote: ...





--
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


Re: Would you expect --perms -M--fake-super to set the file mode to the original one?

2020-03-16 Thread Dimitrios Apostolou via rsync

Thanks. This is a bit counter-intuitive to me. So how would you tell
rsync to store the original permissions in the xattr, but do not touch
the real file mode?

On Thursday, March 12, 2020 6:26:18 PM CET, Kevin Korb via rsync wrote:

I would expect that the sending rsync would only send the perms provided
modified by the --chmod.  I wouldn't expect the receiver to even know
the other permissions.

On 3/12/20 1:23 PM, Dimitrios Apostolou via rsync wrote:

Thank you for the feedback, I'm glad to see that different people see
the issue
differently. As a followup question, what would you expect this to do:

rsync --perms --chmod g+rX -M--fake-super src dst

I would expect it to store the original permissions in the 
xattr, while ...





--
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


Re: Would you expect --perms -M--fake-super to set the file mode to the original one?

2020-03-12 Thread Dimitrios Apostolou via rsync
Thank you for the feedback, I'm glad to see that different people see the 
issue

differently. As a followup question, what would you expect this to do:

rsync --perms --chmod g+rX -M--fake-super src dst

I would expect it to store the original permissions in the xattr, while
modifying the real file mode according to the chmod.

On Thursday, March 12, 2020 6:06:34 PM CET, Kevin Korb via rsync wrote:

Permissions don't require super.  Any place where permissions can't be
stored certainly can't handle xattrs either.  So, I wouldn't expect
--fake-super to affect --perms at all.

On 3/12/20 12:46 PM, Dimitrios Apostolou via rsync wrote:

rsync --perms -M--fake-super src dst

For me, this command means that rsync should save the original 
perms in the
xattr, and leave the real file mode to the umask default. 
Currently it also

modifies the real file mode, and there is no way to store something
different ...





--
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


Would you expect --perms -M--fake-super to set the file mode to the original one?

2020-03-12 Thread Dimitrios Apostolou via rsync

rsync --perms -M--fake-super src dst

For me, this command means that rsync should save the original perms in the
xattr, and leave the real file mode to the umask default. Currently it also
modifies the real file mode, and there is no way to store something 
different

in the xattr.

According to an old bug report that I found, more people would like 
--fake-super to be a complete attribute emulation layer.


https://bugzilla.samba.org/show_bug.cgi?id=7112

Do you agree? I'm in the process of implementing this as a bug fix to 
rsync,

and would like to know if everybody agrees with this behaviour. The patch
would also modify the man page to document it under --perms.


Regards,
Dimitris


--
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


Re: How Can I save the original permissions while setting g+rX for all files

2019-12-08 Thread Dimitrios Apostolou via rsync
Yes indeed, it is setting both the permissions. So it sets the desirable 
access rights to the file, but does not save the original mode in the 
xattr. So it's not really working out for me.



On Monday, December 9, 2019 2:11:23 AM CET, Kevin Korb via rsync wrote:

When I try it the chmod works on both the real permissions and the
permissions in the xatttr.  Maybe the behavior has changed since
whatever version you have (3.1.3 here) but this probably wouldn't help
you either.


On 12/8/19 7:56 PM, Dimitrios Apostolou via rsync wrote:

Hello list!

Combining -M--fake-super with --chmod ends up changing the permissions
stored in the fake-super xattrs. I.e. the permissions stored in the
xattr, are
affected by --chmod. ...





--
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


How Can I save the original permissions while setting g+rX for all files

2019-12-08 Thread Dimitrios Apostolou via rsync

Hello list!

Combining -M--fake-super with --chmod ends up changing the permissions
stored in the fake-super xattrs. I.e. the permissions stored in the xattr, 
are

affected by --chmod.

The desirable behaviour for me would be for --chmod to modify the real
permissions of the destination files. The use case is writing a backup as a
non-root user, having it readable by the group (g+rX), while also saving 
the

original permissions in the xattr.

Is it a bug? Any suggestions on how I can achieve what I want?


Thanks in advance,
Dimitris


--
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