Bug 1064428
Summary: | Support dual mode of password escaping within pgpassfile | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | James W. Mills <jamills> | |
Component: | ovirt-engine-setup | Assignee: | Alon Bar-Lev <alonbl> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Jiri Belka <jbelka> | |
Severity: | high | Docs Contact: | ||
Priority: | urgent | |||
Version: | 3.3.0 | CC: | acathrow, alonbl, bazulay, iheim, jamills, mkalinin, paulds, Rhev-m-bugs, sbonazzo, scohen, tpoitras, yeylon | |
Target Milestone: | --- | Keywords: | ZStream | |
Target Release: | 3.4.0 | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | integration | |||
Fixed In Version: | av2 | Doc Type: | Bug Fix | |
Doc Text: |
Previously, passwords with ':' or '\\' characters were not accepted by .pgpass file in postgresql-8.4. Now, passwords with special characters are accepted.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1067453 (view as bug list) | Environment: | ||
Last Closed: | 2014-06-12 14:04:35 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: | 1067453, 1078909, 1142926 |
Hi, Any chance you have environment I can use for test? Fix is only within one file. Thanks, Alon, I'm happy to test here. I have a freshly installed 3.2.5 env that I can upgrade to test. My env will not be reachable from within RH though. Ar you okay with me performing the test and reporting results? ~james (In reply to James W. Mills from comment #2) > Alon, > > I'm happy to test here. I have a freshly installed 3.2.5 env that I can > upgrade to test. My env will not be reachable from within RH though. Ar > you okay with me performing the test and reporting results? > > ~james Great! Sure I am okay. The sequence is: 1. update ovirt-engine-setup to 3.3 # yum update ovirt-engine-setup 2. apply the patch, should be: # curl http://gerrit.ovirt.org/changes/24407/revisions/a95a363dc8811beb1eb7049aa3ecbbae8b1c7445/patch?download | base64 -d | patch -d /usr/share/ovirt-engine -p2 3. run engine-setup and hopefully we see that all OK. Although it seems a simple issue, it looks like in postgresql-8.4.18-1.el6_4.x86_64 does not accept escape sequence within pgpassfile as it should[1]. In fedora it does require escape sequence. So we need to figure out how to parse and generate the right format of pgpassfile per what supported by the distro. [1] http://www.postgresql.org/docs/8.4/static/libpq-pgpass.html Effected >3.3 packaging/bin/engine-backup.sh packaging/setup/plugins/ovirt-engine-common/base/db/pgpass.py Effected =3.3 packaging/bin/engine-backup.sh packaging/setup/plugins/ovirt-engine-setup/legacy/database.py packaging/setup/plugins/ovirt-engine-common/db/pgpass.py This BZ is for 3.4. Upgrades from 3.2 -> 3.4 is not support, one has to upgrade to next version and not to skip some. Thus I suppose this is impossible to verify. (In reply to Jiri Belka from comment #7) > This BZ is for 3.4. Upgrades from 3.2 -> 3.4 is not support, one has to > upgrade to next version and not to skip some. Thus I suppose this is > impossible to verify. yes... but upgrade from 3.3.z without the fix is. however, 3.3.z will not work without this fix... so there is no point in using it... I agree no verify is required... well, probably because already was needed at bug#1067453 'no verification is required', thus changing status based on comment #8. Closing as part of 3.4.0 |
Description of problem: If a current installation of RHEV uses a password with a colon ":" in it, the logic used to determine if the system is being upgraded or freshly installed is broken Version-Release number of selected component (if applicable): 3.3 How reproducible: 100% Steps to Reproduce: 1. Install RHEV 3.2.5, using the password "passw0rd:" 2. Upgrade to 3.3.X Actual results: Upgrade is treated as a fresh installation instead of an upgrade Expected results: Upgrade is actually an upgrade Additional info: Log errors look like this in a failing case: 2014-02-11 15:59:48 DEBUG otopi.context context.dumpEnvironment:441 ENVIRONMENT DUMP - BEGIN 2014-02-11 15:59:48 DEBUG otopi.context context.dumpEnvironment:456 ENV OVESETUP_CORE/legacyPGCredsFound=bool:'False' 2014-02-11 15:59:48 DEBUG otopi.context context.dumpEnvironment:458 ENVIRONMENT DUMP - END 2014-02-11 15:59:48 DEBUG otopi.context context._executeMethod:123 Stage init METHOD otopi.plugins.ovirt_engine_setup.legacy.core.Plugin._init 2014-02-11 15:59:48 DEBUG otopi.plugins.ovirt_engine_setup.legacy.core core._init:60 versionLocked=True 2014-02-11 15:59:48 DEBUG otopi.context context.dumpEnvironment:441 ENVIRONMENT DUMP - BEGIN 2014-02-11 15:59:48 DEBUG otopi.context context.dumpEnvironment:456 ENV OVESETUP_CORE/upgradeFromLegacy=bool:'False' This is not really helpful, other than to nail down where the upgrade started going wrong. Looking into /usr/share/ovirt-engine/setup/plugins/ovirt-engine-setup/legacy/database.py, however: osetupcons.FileLocations.LEGACY_PSQL_PASS_FILE, 'r', ) as f: for l in f: l = l.rstrip('\n') d = l.split(':') if len(d) == 5 and d[3] == legacy_user: In the case where users have a password with a ":" in them, the field length is 6. Example: $ cat .pgpass localhost:5432:*:postgres:passw0rd: localhost:5432:*:engine:passw0rd: localhost:5432:rhevm:rhevm:passw0rd: >>> with open('.pgpass', 'r') as f: ... for l in f: ... l = l.rstrip('\n') ... d = l.split(':') ... print len(d) ... 6 6 6 Passwords with a ":" will never be correctly interpreted with this logic.