On 05/02/18 23:03, Dave Gordon via rsync wrote:
> On 05/02/18 05:53, Wayne Davison wrote:
>> On Sat, Feb 3, 2018 at 5:20 AM, Dave Gordon via rsync
>> <rsync@lists.samba.org <mailto:rsync@lists.samba.org>> wrote:
>>
>> [...fake-super symlink saved as a file...]
>>
>> This results in the copy being world-writable.
>>
>> Indeed. The file initially gets created as a mode-600 file, but the code
>> later tweaks the permissions to match the symlink, which is (as you
>> note) a bad thing.
>>
>> My first reaction is to change the code in set_stat_xattr()
>> (in xattrs.c) from:
>>
>> if (fst.st_mode != mode)
>> do_chmod(fname, mode);
>>
>> to:
>>
>> if (fst.st_mode != mode && !S_ISLNK(file->mode))
>> do_chmod(fname, mode);
>>
>> ..wayne..
>
> That's certainly an improvement; from the safety point of view, leaving
> it as 0600 is a lot better than leaving it as 0777. I'm currently
> investigating a slightly more extensive fix to allow more control over
> how fake-symlink files end up, also to make fake-super work better with
> incoming-chmod for the daemon case.
>
> .Dave.
The other part of this problem is that it doesn't at present seem
possible to satisfy all of three individually reasonable requirements of
a backup system at the same time:
1. The backup receiver (daemon) need not run as root.
2. The backup daemon should preserve all of the client's metadata.
3. The backup daemon should have control over modes, ownership, etc
of the backup files.
1 & 2 can be satisfied today with the use of --fake-super, but even
apart from the issue with 0777 symlinks, the modes of the backup files
are based on those of the originals .. unless you use chmod.
1 & 3 can be satisfied together by using --fake-super with --chmod on
the receiving side or incoming-chmod in the daemon config. But this
actually loses information as it affects not only the modes of the
backup files, but also the state saved in user.rsync.%stat.
So my proposal would be for the receiving-side chmod to be applied (in
fake mode) *after* user.rsync.%stat has been saved, and likewise after
the conversion of symlinks (et al.) to plain files.
This would allow a daemon configuration containing both fake-super and
an absolute setting for incoming-chmod to fulfil all three of the above.
The logical flow for a push-to-fake-super-daemon would then be:
1. client sends filespecs, applying any local --chmod on the way
2. daemon receives filespecs, does *not* tweak_mode at this stage
3. ... data transfer as needed ...
4. daemon sets backup file attributes
4a. in fake mode, daemon saves user.rsync.%stat, then applies
tweak_mode() to the local file. Daemon modes take precedence
as expected.
4b. in non-fake mode, the daemon just applies the deferred
tweak_mode(). This may lose information, as at present
(because that's *also* useful).
The reverse flow (pull-from-fake-super-daemon) is:
1. daemon sends filespecs, getting modes from user.rsync.%stat
(daemon would apply outgoing-chmod here, but I don't think it
would be set in this configuration).
2. client receives filespecs, does *not* tweak_mode at this stage
3. ... date transfer as needed ...
4. client sets local file attributes
4b. (non-fake-mode) client applies any local --chmod
Any client-local --chmod is applied later in this flow than at present,
but that should make no difference. Note that the client didn't need to
know (and shouldn't be able to tell?) whether the daemon was super or
just faking it :)
.Dave.
--
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
