Bug 1722229
Summary: | scp protocol error: filename does not match request causing Oracle 18c Grid to not install | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Daniel Yeisley <dyeisley> |
Component: | openssh | Assignee: | Jakub Jelen <jjelen> |
Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
Severity: | urgent | Docs Contact: | |
Priority: | low | ||
Version: | 8.1 | CC: | tmraz |
Target Milestone: | rc | Keywords: | Documentation, Regression, Triaged |
Target Release: | 8.0 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-01-05 16:41:33 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: | |||
Bug Depends On: | |||
Bug Blocks: | 1708794 |
Description
Daniel Yeisley
2019-06-19 18:10:56 UTC
I don't have a problem from the command line. I'm not sure what the installer is doing differently. [root@veritas6 ~]# /usr/bin/scp -p veritas7:'/tmp/GridSetupActions2019-06-19_02-13-10PM/CVU_18.0.0.0.0_oracle/scratch/getFileInfo6801.out' /tmp/GridSetupActions2019-06-19_02-13-10PM/veritas7.getFileInfo6801.out getFileInfo6801.out 100% 102 149.7KB/s 00:00 I think this is caused by the fix for CVE-2019-6111 [1]. In this case, the problem are the apostrophes around the filaname. You should be able to workaround this by using -T switch to skip the strict checks (see openssh release notes [2]) or use SFTP in batch mode instead (preferred). This is indeed a change in a behavior of a legacy tool, but unfortunately nothing we can change or fix. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1666127 [2] http://www.openssh.com/txt/release-8.0 (In reply to Jakub Jelen from comment #2) > I think this is caused by the fix for CVE-2019-6111 [1]. In this case, the > problem are the apostrophes around the filaname. You should be able to > workaround this by using -T switch to skip the strict checks (see openssh > release notes [2]) or use SFTP in batch mode instead (preferred). > > This is indeed a change in a behavior of a legacy tool, but unfortunately > nothing we can change or fix. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1666127 > [2] http://www.openssh.com/txt/release-8.0 I do not have the ability to modify Oracle's install code. The best I can do is set an environment variable to tell the installer what scp to use. So I created a script that calls 'scp -T' and pointed the installer at that. [oracle@veritas6 grid]$ export ORACLE_SRVM_REMOTECOPY=/grid/scp [oracle@veritas6 grid]$ cat /grid/scp #!/bin/sh /usr/bin/scp -T $* Adding the '-T' option to the environment variable doesn't work. I tried export ORACLE_SRVM_REMOTECOPY="/grid/scp -T" and the installer bailed out right away. Can you show the debug log with the /grid/scp set up? Is it different than the previous attempts? (In reply to Jakub Jelen from comment #4) > Can you show the debug log with the /grid/scp set up? Is it different than > the previous attempts? I put my scp script in /tmp. It looks like the successful output. [Worker 2] [ 2019-06-21 11:48:52.588 EDT ] [VerificationUtil.getDestLoc:4696] ==== CV_DESTLOC(pre-fetched value): '/tmp/GridSetupActions2019-06-21_11-44-06AM/' [Worker 2] [ 2019-06-21 11:48:52.588 EDT ] [UnixSystem.copyFile:1097] Copy file veritas7:/tmp/GridSetupActions2019-06-21_11-44-06AM/CVU_18.0.0.0.0_oracle/scratch/getFileInfo31138.out to localnode:/tmp/GridSetupActions2019-06-21_11-44-06AM/veritas7.getFileInfo31138.out [Worker 2] [ 2019-06-21 11:48:52.588 EDT ] [Utils.getLocalHost:479] Hostname retrieved: veritas6.6a2m.lab.eng.bos.redhat.com, returned: veritas6 [Worker 2] [ 2019-06-21 11:48:52.588 EDT ] [UnixSystem.remoteCopyFile:821] Copying files veritas7/tmp/GridSetupActions2019-06-21_11-44-06AM/CVU_18.0.0.0.0_oracle/scratch/getFileInfo31138.out localnode/tmp/GridSetupActions2019-06-21_11-44-06AM/veritas7.getFileInfo31138.out [Worker 2] [ 2019-06-21 11:48:52.588 EDT ] [Utils.getLocalHost:479] Hostname retrieved: veritas6.6a2m.lab.eng.bos.redhat.com, returned: veritas6 [Worker 2] [ 2019-06-21 11:48:52.588 EDT ] [Utils.getLocalHost:479] Hostname retrieved: veritas6.6a2m.lab.eng.bos.redhat.com, returned: veritas6 [Worker 2] [ 2019-06-21 11:48:52.588 EDT ] [UnixSystem.remoteCopyFile:839] UnixSystem: /tmp/scp -p veritas7:'/tmp/GridSetupActions2019-06-21_11-44-06AM/CVU_18.0.0.0.0_oracle/scratch/getFileInfo31138.out' /tmp/GridSetupActions2019-06-21_11-44-06AM/veritas7.getFileInfo31138.out [Thread-432] [ 2019-06-21 11:48:52.589 EDT ] [StreamReader.run:62] In StreamReader.run [Worker 2] [ 2019-06-21 11:48:52.589 EDT ] [RuntimeExec.runCommand:294] runCommand: Waiting for the process [Thread-431] [ 2019-06-21 11:48:52.589 EDT ] [StreamReader.run:62] In StreamReader.run [Worker 2] [ 2019-06-21 11:48:53.192 EDT ] [RuntimeExec.runCommand:296] runCommand: process returns 0 [Worker 2] [ 2019-06-21 11:48:53.193 EDT ] [RuntimeExec.runCommand:323] RunTimeExec: error> [Worker 2] [ 2019-06-21 11:48:53.193 EDT ] [RuntimeExec.runCommand:349] Returning from RunTimeExec.runCommand [Worker 2] [ 2019-06-21 11:48:53.193 EDT ] [NativeSystem.isCmdScv:580] isCmdScv: cmd=[/tmp/scp -p veritas7:'/tmp/GridSetupActions2019-06-21_11-44-06AM/CVU_18.0.0.0.0_oracle/scratch/getFileInfo31138.out' /tmp/GridSetupActions2019-06-21_11-44-06AM/veritas7.getFileInfo31138.out] [Worker 2] [ 2019-06-21 11:48:53.193 EDT ] [NativeSystem.isCmdScv:630] isCmdScv: /tmp/scp is present. [Worker 2] [ 2019-06-21 11:48:53.193 EDT ] [NativeSystem.isCmdScv:632] isCmdScv: /tmp/scp is a file. [Worker 2] [ 2019-06-21 11:48:53.193 EDT ] [NativeSystem.isCmdScv:649] isCmdScv: returned true [Worker 2] [ 2019-06-21 11:48:53.193 EDT ] [NativeSystem.rununixcmd:1324] NativeSystem.rununixcmd: RetString 1| :successful [Worker 2] [ 2019-06-21 11:48:53.193 EDT ] [GetFileInfoCommand.processOutputFile:204] <FILE><NAME,/home/oracle/.ssh/id_rsa><STATUS,0><USER,oracle><GROUP,oinstall><PERMISSIONS,0600></FILE> [Worker 2] [ 2019-06-21 11:48:53.193 EDT ] [Utils.getLocalHost:479] Hostname retrieved: veritas6.6a2m.lab.eng.bos.redhat.com, returned: veritas6 [Thread-434] [ 2019-06-21 11:48:53.194 EDT ] [StreamReader.run:62] In StreamReader.run [Worker 2] [ 2019-06-21 11:48:53.195 EDT ] [RuntimeExec.runCommand:294] runCommand: Waiting for the process [Thread-433] [ 2019-06-21 11:48:53.195 EDT ] [StreamReader.run:62] In StreamReader.run [Worker 2] [ 2019-06-21 11:48:53.780 EDT ] [RuntimeExec.runCommand:296] runCommand: process returns 0 [Worker 2] [ 2019-06-21 11:48:53.780 EDT ] [RuntimeExec.runCommand:323] RunTimeExec: error> [Worker 2] [ 2019-06-21 11:48:53.780 EDT ] [RuntimeExec.runCommand:349] Returning from RunTimeExec.runCommand [root@veritas6 Certification]# rpm -qa | grep openssh openssh-server-8.0p1-1.el8.x86_64 openssh-clients-8.0p1-1.el8.x86_64 openssh-8.0p1-1.el8.x86_64 [root@veritas6 Certification]# cat /tmp/scp #!/bin/sh /usr/bin/scp -T $* Nice. Thank you for the verification. I understand that this is not an ideal solution, but it is best we have. Is this something you can live with for now or something that can be addressed on oracle side in future? I could propose to store the script rather in /usr/bin/insecure-scp or something like that for the installer (not sure whether it is needed later in the process or only in the installer). (In reply to Jakub Jelen from comment #6) > Nice. Thank you for the verification. I understand that this is not an ideal > solution, but it is best we have. Is this something you can live with for > now or something that can be addressed on oracle side in future? > > I could propose to store the script rather in /usr/bin/insecure-scp or > something like that for the installer (not sure whether it is needed later > in the process or only in the installer). I can live with it. Ideally Oracle would update their code, but I have no idea how long that will take. Creating /usr/bin/insecure-scp sounds good to me. I probably would not put it in the directory on $PATH. Maybe /usr/libexec/scp-T would be better. With some appropriate comment in the script. (In reply to Jakub Jelen from comment #6) > Nice. Thank you for the verification. I understand that this is not an ideal > solution, but it is best we have. Is this something you can live with for > now or something that can be addressed on oracle side in future? > > I could propose to store the script rather in /usr/bin/insecure-scp or > something like that for the installer (not sure whether it is needed later > in the process or only in the installer). So what's happening with this? I am sorry if it was not clear from the last comment. I do not think it is a good idea to provide this script from the base openssh package and teach people to use it without thinking so the previous comments were mainly addressing your installer scripts, that could create this workaround file as a short-term solution and fixing the oracle installer as a long-term solution. I did not close this bug so far to keep it visible if somebody else will encounter same issue to serve as a landing page and simple way to find a workaround and a root cause. Does it make sense? (In reply to Jakub Jelen from comment #11) > I am sorry if it was not clear from the last comment. > > I do not think it is a good idea to provide this script from the base > openssh package and teach people to use it without thinking so the previous > comments were mainly addressing your installer scripts, that could create > this workaround file as a short-term solution and fixing the oracle > installer as a long-term solution. > > I did not close this bug so far to keep it visible if somebody else will > encounter same issue to serve as a landing page and simple way to find a > workaround and a root cause. > > Does it make sense? So we fix this with documentation? I don't have a problem creating a simple script to work around the issue. Yes, we certainly plan to mention something along the lines in the RHEL 8.1 release notes because of the rebase and this CVE fix, which is causing this behavior. We kept this bug open for some time after RHEL8.0 if others would experience the same issue. This was documented in Release notes under section "OpenSSH rebased to 8.0p1": https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.1_release_notes/rhel-8_1_0_release We do not plan to fix/change this anyhow so I am closing the bug now. |