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-setupAssignee: Alon Bar-Lev <alonbl>
Status: CLOSED CURRENTRELEASE QA Contact: Jiri Belka <jbelka>
Severity: high Docs Contact:
Priority: urgent    
Version: 3.3.0CC: 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    

Description James W. Mills 2014-02-12 15:37:53 UTC
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.

Comment 1 Alon Bar-Lev 2014-02-12 18:10:04 UTC
Hi,

Any chance you have environment I can use for test?

Fix is only within one file.

Thanks,

Comment 2 James W. Mills 2014-02-12 20:20:02 UTC
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

Comment 3 Alon Bar-Lev 2014-02-12 20:30:20 UTC
(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.

Comment 4 Alon Bar-Lev 2014-02-12 23:51:40 UTC
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

Comment 5 Alon Bar-Lev 2014-02-13 00:04:40 UTC
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

Comment 7 Jiri Belka 2014-03-07 12:05:04 UTC
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.

Comment 8 Alon Bar-Lev 2014-03-07 12:08:42 UTC
(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

Comment 9 Jiri Belka 2014-03-07 12:26:18 UTC
'no verification is required', thus changing status based on comment #8.

Comment 10 Itamar Heim 2014-06-12 14:04:35 UTC
Closing as part of 3.4.0