Bug 2048560

Summary: REX doesn't honor effective_user when async_ssh is true
Product: Red Hat Satellite Reporter: Joniel Pasqualetto <jpasqual>
Component: Remote ExecutionAssignee: Adam Ruzicka <aruzicka>
Status: CLOSED ERRATA QA Contact: Peter Ondrejka <pondrejk>
Severity: high Docs Contact:
Priority: high    
Version: 6.10.1CC: ahumbe, aruzicka, ehelms, jsenkyri, lstejska, pcreech, pondrejk
Target Milestone: 6.11.0Keywords: Regression, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tfm-rubygem-smart_proxy_remote_execution_ssh-0.5.3 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-07-05 14:32:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Joniel Pasqualetto 2022-01-31 14:13:43 UTC
Description of problem:
When option async_ssh is true and remote_execution_ssh_user is not root, the resulting job is not executed with the effective_user on the target server

Version-Release number of selected component (if applicable):
satellite 6.10.2

How reproducible:
always

Steps to Reproduce:
1. Configure async_ssh to true:

~~~
# grep async /etc/foreman-proxy/settings.d/remote_execution_ssh.yml 
# Whether to run remote execution jobs asynchronously
:async_ssh: true
~~~

2. Configure remote_execution_ssh_user to a regular user and define remote_execution_effective_user_method to sudo

3. Initiate a job to run "whoami" on a target host. Check the output of the job and you'll see the regular user, instead of root.

4. Change the async_ssh back to false, and run the same job again. You'll see root on the output. 

Actual results:
job is execute with the regular user.

Expected results:
job to be executed with root

Additional info:

Comment 1 Jan Senkyrik 2022-01-31 16:08:56 UTC
FYI this is not reproducible on Satellite 6.9

Comment 5 Adam Ruzicka 2022-02-01 15:13:18 UTC
Created redmine issue https://projects.theforeman.org/issues/34368 from this bug

Comment 6 Bryan Kearney 2022-02-01 16:05:35 UTC
Upstream bug assigned to aruzicka

Comment 7 Bryan Kearney 2022-02-01 16:05:37 UTC
Upstream bug assigned to aruzicka

Comment 9 Bryan Kearney 2022-02-05 02:18:53 UTC
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/34368 has been resolved.

Comment 13 Adam Ruzicka 2022-02-08 14:03:22 UTC
Alright, rephrasing as a public comment.

Password-less effective user with async_ssh used to work some time in the past,
so this indeed is a regression.

On the other hand, if I'm reading things right, effective user with password and
async ssh never worked at all.

This BZ will cover only the use case when password is NOT required to change the
user on the remote host. Or to put it differently, thiz BZ deals with only
password-less variants of the effective user methods. This allows us to make the
change simple and small and even deliver it into Z-streams.

The changes necessary for making effective user with password and async ssh
working will be much larger and will be tracked as a separate BZ to allow us
to do it properly. BZ #2051999 is the BZ tracking this effort.

Comment 14 Peter Ondrejka 2022-02-14 16:06:18 UTC
Checked on Satellite 7.0 snap 9, a rex job with assync_ssh:true and effective user specified (password-less sudo) hangs in the pending state until connection timeout. Unfortunately, I couldn't find anything revealing in logs. 

Root user with assync_ssh:true works as expected, same for effective user with assync_ssh:false

Comment 15 Adam Ruzicka 2022-02-14 17:00:50 UTC
Could I take a look at the machine? It worked just fine on a machine I just deployed.

Comment 16 Adam Ruzicka 2022-03-21 13:59:15 UTC
Alright, after investigating pondrejk's machine I must admit this indeed does not work when the effective user is non-root, whereas in #15 I was testing non-root connection user and root effective user

Comment 18 Peter Ondrejka 2022-04-14 12:41:29 UTC
Verified on Satellite 6.11 snap 16, effective user is accepted when running rex jobs even if going from root to non-root.

Comment 21 errata-xmlrpc 2022-07-05 14:32:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Satellite 6.11 Release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:5498