download_file doesn't use run-as for all the commmands

[krisavi]

Describe the Bug

During download_file when run-as is used then portion of the commands are run with connecting user. Folder in temp is generated by connecting user. Copying to this temp folder is then performed using the run-as user and it will fail because the mask 700 doesn't give any permissions to other users or groups.

Expected Behavior

All of the commands are being run as the same user. Or at directory is made with same group as run-as user and write privileges given to there.

Steps to Reproduce

Steps to reproduce the behavior:

1. Create plan where default user is different from run-as user and use download_file to download file from the targets.
2. Run the plan on some target.

Environment

• Version 4.0.0
• Platform AlmaLinux 8.10 (Cerulean Leopard)

Additional Context

I left comment in ticket #2679 which resulted in making it possible to function the way it is functioning now.

Downloading: '/var/lib/pgsql/dumps' on pg1.infra.local to /home/kris/bolty/downloads/pg_dumps/pg1.infra.local 
Starting: file download from /var/lib/pgsql/dumps to home/kris/bolty/downloads/pg_dumps/ on pg1.infra.local 
Started on pg1.infra.local...
Executing `mkdir -m 700 /tmp/c3489030-1f0a-4dd2-b880-c0c577f2d738`
Command `mkdir -m 700 /tmp/c3489030-1f0a-4dd2-b880-c0c577f2d738` returned successfully
Executing `sudo -S -H -u postgres -p \[sudo\]\ Bolt\ needs\ to\ run\ as\ another\ user,\ password:\  sh -c cd\;\ cp\ -r\ /var/lib/pgsql/dumps\ /tmp/c3489030-1f0a-4dd2-b880-c0c577f2d738`
Command sudo -S -H -u postgres -p \[sudo\]\ Bolt\ needs\ to\ run\ as\ another\ user,\ password:\  sh -c cd\;\ cp\ -r\ /var/lib/pgsql/dumps\ /tmp/c3489030-1f0a-4dd2-b880-c0c577f2d738 failed with exit code 1
Executing `rm -rf /tmp/c3489030-1f0a-4dd2-b880-c0c577f2d738`
Command `rm -rf /tmp/c3489030-1f0a-4dd2-b880-c0c577f2d738` returned successfully
{"target":"pg1.infra.local","action":"download","object":null,"status":"failure","value":{"_error":{"details":{"file":"/home/kris/bolty/plans/download_dumps.pp","line":20},"kind":"puppetlabs.tasks/task_file_error","msg":"Could not copy file '/var/lib/pgsql/dumps' to temporary directory '/tmp/c3489030-1f0a-4dd2-b880-c0c577f2d738': cp: cannot stat '/tmp/c3489030-1f0a-4dd2-b880-c0c577f2d738/dumps': Permission denied\n","issue_code":"CP_ERROR"}}}
Failed on pg1.infra.local:
  Could not copy file '/var/lib/pgsql/dumps' to temporary directory '/tmp/c3489030-1f0a-4dd2-b880-c0c577f2d738': cp: cannot stat '/tmp/c3489030-1f0a-4dd2-b880-c0c577f2d738/dumps': Permission denied
Finished: file download from /var/lib/pgsql/dumps to /home/kris/bolty/downloads/pg_dumps/ with 1 failure in 4.45 sec

[krisavi]

I don't think there is a good solution to it security wise. When same group is added and write permissions to group then there is slim chance that some other process sticks files in there during this small window. It is lower when only user has privileges, however temp directory cannot be created as run-as user either. Copying would work but downloading using connected user wouldn't. Connecting user couldn't give away ownership of the directory to another user without root user involvement.

Currently download_file has any usefulness from run-as user only when it is run as root user. That way it can ignore permission checks when writing to directory they don't own.