Issue with oracledb_session and sudo on UNIX

I'm having a problem attempting to use inspec and oracledb_session to a Solaris 11.4 box from a gitlab runner. The command being executed from the runner is:

bundle exec inspec exec . -t ssh://${GITLABUSER}@${host} --log_level=debug --sudo --sudo-password=${SUDO_PASSWORD} --input-file ${INPUTFILE} ${STAGEFILE} --reporter cli junit:$host-compliance_report.xml --chef-license=accept-silent

From the log output I get something like:

D, [2021-10-22T18:22:33.812805 #19961] DEBUG -- : [SSH] gitlabuser@somedbhost cmd = echo Tm90IFJlYWxseSBUaGUgUGFzc3dvcmQK | base64 --decode | sudo -S sqlplus -S "Redacted Login Credentials" <<'EOC'
SET PAGESIZE 32000
SET FEEDBACK OFF
SET UNDERLINE OFF
SELECT ROLE FROM DBA_ROLES WHERE ROLE = 'SOME_ROLE';
EXIT
EOC

Now what is happenning here is that when this runs, sudo appears to be taking it's stdin from the here document rather than the pipe. I've been able to verify this with a simple test:

$ cat /tmp/testscript
#!/bin/sh 
echo in the script
cat
$ echo Tm90IFJlYWxseSBUaGUgUGFzc3dvcmQK | base64 --decode | sudo -S /tmp/t <<!
here doc input
!

we get:

Password: Sorry, try again.
Password:
sudo: no password was provided
sudo: 1 incorrect password attempt
sudo: [ID 183074 authpriv.alert] gitlabuser : 1 incorrect password attempt ; TTY=pts/8 ; PWD=/tmp ; USER=root ; COMMAND=/tmp/testscript

Which if done enough results in AD locking out the user.

So, I guess my question is, am I hitting a bug that has been addressed since Jan 21 2020 or is something else weird going on here to produce this cmd?

The codebase we are using has a last commit of Jan 21 2020. We've updated a number of fixes to lib/inspec/resources/oracledb_session.rb and it's not too far off current. Resynching to a current tree may cause us issues with the code we had to add to get Solaris target supported (but if required could possibly be done).

Regards,
Alan Hargreaves

If anyone is actually using oracle_session with a UNIX/Linux based target, I would be most interested if you could do a run with --log-level=debug and show me what the "cmd" getting run is (obvious redacting secret stuff), just to make sure I've not missed a change to the way sudo is working inspec.

Meanwhile, I'm going to start looking at pulling a current copy of the code and porting the changes we did for Solaris support.

Regards,
Alan Hargreaves