allow sudo to preserve permissions with rsync

[sdondley]

This simple patch attempts to correct a problem with rsync that I was having. rysnc was not retaining file ownership even with the --archive option.

I'm not sure if this patch is the best approach but it does work.

[ferki]

Could you clarify your exact use case with some examples, please?

The code already seems to add --rsync-path='sudo rsync' to the list of rsync options when the current operation is executed with sudo, and I'd like to understand in exactly which situations it's not enough.

Would we also need different settings for different cases (e.g. download vs upload), perhaps?

I don't think we can easily write tests for combining rsync with sudo, so it feels like it is worth to pay some extra attention with modifications, and at least try to have some examples for reference.

[sdondley]

The use case is to be able to run rsync as the root user on the local machine so you can create files with ownership from other users on the local machine. Although sudo is run on the remote machine, you also need the command to be run as sudo locally. My patch slaps a sudo in front of the command to accomplish this.

When I used the rex sync command, files saved to the local machine did not have the same file ownership as the files on the remote machine. The only way I found to preserve ownership was to place sudo in front of the rsync command.

It's definitely possible I just don't know how to properly use the rex sync command to retain file ownership settings and this patch may not be needed at all.

[ferki]

I mean there are two use cases with rsync: upload or download.

When uploading from local, the remote side has to run rsync with sudo if the currently logged in user's normal permissions are not enough to manage the destination paths. That's why

if (Rex::is_sudo) {
     push @rsync_cmd, "--rsync-path='sudo rsync'";
};

is there.

When downloading to local, the reverse might be true: the local rsync command might need to be run with sudo, if the current user's permissions are not enough to manage the destination paths. In that case, I can imagine you'd need something like your patch:

unshift @rsync_cmd, 'sudo';

This change would also imply that we have to deal with different authentication data as well (e.g. the remote sudo password might be different than the local one).

On top of that, it might be the case that both sudo are needed in all cases, or just some of those sudos are needed depending on what the user is trying to do (upload/download).

In order to reduce the complexity of a solution we might be able to avoid the whole "multiple authentication data is involved" problem domain perhaps by using --super or --fake-super with rsync. Those seem to be there exactly for this purpose, and that might mean we don't even need to modify rex, just pass an extra option to rsync.

Excerpt from man rsync:

--super: This tells the receiving side to attempt super-user activities even if the receiving rsync wasn't run by the super-user. [...]

--fake-super: When this option is enabled, rsync simulates super-user activities by saving/restoring the privileged attributes via special extended attributes that are attached to each file (as needed). [...]

[sdondley]

Perhaps I'm not using the switches correctly, but neither --super or --fake-super worked. Here is the command I'm using:

rsync -rl -e 'ssh -i /home/user/key.pem -o StrictHostKeyChecking=no -p 22' --verbose --stats --delete --archive --super 'bitnami@my_host:/home/user/rsync_from' '/home/user/rsync_to'

[sdondley]

I think, if I'm not mistaken, that even when uploading files, you will still want to run rsync under sudo locally. This is because the current user running under rsync may not have the proper permission to read the files being uploaded.

If I am right, there is no difference between upload and download operations. Both would require sudo.

[ferki]

Perhaps I'm not using the switches correctly, but neither --super or --fake-super worked.

Hmm, not so good news, but these flags are new for me too, so I'll also need to play with them a bit more.

I think, if I'm not mistaken, that even when uploading files, you will still want to run rsync under sudo locally. This is because the current user running under rsync may not have the proper permission to read the files being uploaded.

Yes, this is a good point, I think you're right with that scenario.

I was also trying to think about all the details of the different cases, but didn't have the chance to test all of the out yet. I wish these could be represented as proper test cases, but I don't see any easy/reliable way yet to emulate rsync with sudo.

(Note to self: perhaps it can be at least cross-checked later with test cases in RexOps/rex-build, once that repo is resurrected properly.)

If I am right, there is no difference between upload and download operations. Both would require sudo.

Right, following up on the above we would need elevated permissions on both the sender and receiver ends.