Bug 1956750
| Summary: | Python oVirt SDK overwrites /dev/null with cookie file | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine-sdk-python | Reporter: | Richard W.M. Jones <rjones> | ||||
| Component: | General | Assignee: | Ori Liel <oliel> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Guilherme Santos <gdeolive> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.4.11 | CC: | ahadas, bugs, gdeolive, juan.hernandez, juzhou, lleistne, lsvaty, mperina, mxie, oliel, rduda, rjones, tyan, tzheng, virt-bugs, virt-maint, xiaodwan, zpytela | ||||
| Target Milestone: | ovirt-4.4.7 | Keywords: | Automation, TestBlocker, Triaged | ||||
| Target Release: | --- | Flags: | pm-rhel:
ovirt-4.4+
lsvaty: blocker- gdeolive: testing_ack+ |
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | python3-ovirt-engine-sdk4-4.4.13 | Doc Type: | No Doc Update | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | 1939387 | Environment: | |||||
| Last Closed: | 2021-07-06 07:28:06 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1939387 | ||||||
| Attachments: |
|
||||||
|
Description
Richard W.M. Jones
2021-05-04 11:02:37 UTC
Created attachment 1779700 [details]
ovirt-engine-sdk-python-4.4.10-remove-bogus-cookiejar.patch
The fix is simply to remove the two lines setting COOKIEFILE
and COOKIEJAR. Both lines are incorrect.
*** Bug 1953476 has been marked as a duplicate of this bug. *** This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP. This is not a blocker for RHV 4.4.6, the code is there from RHV 4.0, we will try to fix in RHV 4.4.7 (In reply to Martin Perina from comment #4) > This is not a blocker for RHV 4.4.6, the code is there from RHV 4.0, we will > try to fix in RHV 4.4.7 This is a serious bug that affects virt-v2v when run as root (actually damaging the hosts that virt-v2v runs on), and the change is a two line fix that has already been tested by QE. Please fix it. (In reply to Richard W.M. Jones from comment #5) > (In reply to Martin Perina from comment #4) > > This is not a blocker for RHV 4.4.6, the code is there from RHV 4.0, we will > > try to fix in RHV 4.4.7 > > This is a serious bug that affects virt-v2v when run as root (actually > damaging > the hosts that virt-v2v runs on), and the change is a two line fix that has > already been tested by QE. Please fix it. Those 2 particular lines has been added in RHV 4.1 to support asynchronous request (more info in BZ1436981). RHV 4.4.6 is now in blocker only mode, meaning that this change would mean that QE would need to reverify the whole asynchronous request feature. Lucie, are you OK to do that? Is that true? The change you're referring to just moves the incorrect code, it doesn't add those: https://gerrit.ovirt.org/c/ovirt-engine-sdk/+/76041/5/sdk/lib/ovirtsdk4/__init__.py (In reply to Martin Perina from comment #6) > (In reply to Richard W.M. Jones from comment #5) > > (In reply to Martin Perina from comment #4) > > > This is not a blocker for RHV 4.4.6, the code is there from RHV 4.0, we will > > > try to fix in RHV 4.4.7 > > > > This is a serious bug that affects virt-v2v when run as root (actually > > damaging > > the hosts that virt-v2v runs on), and the change is a two line fix that has > > already been tested by QE. Please fix it. > > Those 2 particular lines has been added in RHV 4.1 to support asynchronous > request (more info in BZ1436981). RHV 4.4.6 is now in blocker only mode, > meaning that this change would mean that QE would need to reverify the whole > asynchronous request feature. > Lucie, are you OK to do that? Correction, so actually the code around COOKIEFILE and COOKIEJAR is in the Python SDK since 2014, when we switched to pycurl: https://gerrit.ovirt.org/33064 Hi Martin, with the fixed merged, we can test it for 4.4.6 0day. We can run a patch with the examples used to verify BZ1436981 and other sdk functionalities and verify based on that cookie-file' and 'cookie-jar' were set to /dev/null in order to make libcurl store cookies only in memory, rather than be written to a file (this is done for security reasons, as sometimes these files are not cleaned-up properly, for example in case of a crash in the system). Removing this configuration will revert to the default behavior of the library, which is that cookies are disabled. I'm in the process of understanding the implications of this, but it's not trivial. For example, Engine old implementation of session-based authentication relies on cookies, so clients scripts with session-based authentication making requests to old versions of the Engine (I'm trying to determine how old) are expected to break. I don't have a ready environment to test this, but I have reason to believe that removing only the cookie-jar line, and leaving the cookie-file line as is, can both preserve the current mode of working with cookies and solve the bug. Is that something that can be quickly tested? (thanks to Juan Hernandez (@jhernand), author of the python-sdk, for helping me with this infomration) Setting these to /dev/null was not the correct way to do this. The documentation of curl is very confusing, I found it was better to go straight to the sources, but this is what you need to do: - Do not set COOKIEJAR at all. - Set COOKIEFILE to the empty string "" soon after creating the handle. This enables cookie processing. - As long as you never set COOKIEJAR and never use COOKIELIST, no cookies will be written out. You can test this using a simple Python script: -------------- #!/usr/bin/python3 import pycurl c = pycurl.Curl() c.setopt(pycurl.COOKIEFILE, "") # This URL is chosen because it redirects and sets cookies. c.setopt(pycurl.URL, "http://ibm.com") c.setopt(pycurl.FOLLOWLOCATION, 1) # Enable verbose output so we can see what it's doing. c.setopt(pycurl.VERBOSE, 1) c.perform() Verified on: ovirt-engine-sdk-python==4.4.13 Steps: 1. # ll -Z /dev/null crw-rw-rw-. 1 root root system_u:object_r:null_device_t:s0 1, 3 Jul 2 12:48 /dev/null 2. Run script used to verify the sync bug BZ1436981 mention on comment #6 3. # ll -Z /dev/null crw-rw-rw-. 1 root root system_u:object_r:null_device_t:s0 1, 3 Jul 2 12:48 /dev/null 4. Run valitation script provided in comment #11 5. # ll -Z /dev/null crw-rw-rw-. 1 root root system_u:object_r:null_device_t:s0 1, 3 Jul 2 12:48 /dev/null Results: ovirt-sdk not screwing /dev/null and working properly as expected This bugzilla is included in oVirt 4.4.7 release, published on July 6th 2021. Since the problem described in this bug report should be resolved in oVirt 4.4.7 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. *** Bug 1939387 has been marked as a duplicate of this bug. *** |