Project board link

Issue Summary:

When attempting to perform cluster restore with use_sudo_for_restore set to false, the restore-node command is still executed with sudo privileges due to an incorrect conditional check. This behaviour deviates from expected functionality and could lead to unsuccessful backups and security concerns.

Steps to Reproduce:

1. Configure use_sudo_for_restore to false in the medusa.ini configuration.
2. Initiate a cluster backup operation.
3. Observe the logs of the restore show:

INFO: Executing "mkdir -p <temp-file>; cd <temp-file> && medusa-wrapper sudo medusa  --fqdn=%s -vvv restore-node --in-place  %s --no-verify --backup-name <backup name>--temp-dir <temp-dir>   " on following nodes ['IP1', 'IP2', 'IP3'] with a parallelism/pool size of 500

Expected Behaviour:

The restore-node command should not be executed with sudo privileges when use_sudo_for_restore is set to false, ensuring consistency with the configuration option.

Actual Behavior:

The restore-node command is still executed with sudo privileges, irrespective of the value of use_sudo_for_restore.

Additional Context:

Upon reviewing the codebase, it appears that the conditional check used to determine whether the restore-node command should run with sudo privileges checks config.cassandra.use_sudo instead of use_sudo_for_restore, which is the variable used for medusa running as sudo for the majority of commands, but should not be able to override use_sudo_for_restore. This discrepancy leads to the observed behaviour.

Proposed Solution:

Adjust the conditional check in the codebase to properly utilise the use_sudo_for_restore configuration option when determining whether the restore-node command should run with sudo privileges.

Impact:

This issue affects users who rely on the use_sudo_for_restore configuration option to control sudo usage during cluster backup operations. Resolving this issue will ensure consistent behavior and improve security by correctly respecting user configurations.

Environment:

• Cassandra-Medusa version: 0.19.1
• Operating System: 20.04.1-Ubuntu
• medusa.ini Storage Details:

[storage]
storage_provider = s3
use_sudo_for_restore = False
key_file = /home/medusa/.aws/credentials
bucket_name = <s3 bucket name>
multi_part_upload_threshold = 0

┆Issue is synchronized with this Jira Story by Unito
┆Issue Number: MED-15