Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1064428 - Support dual mode of password escaping within pgpassfile
Summary: Support dual mode of password escaping within pgpassfile
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup
Version: 3.3.0
Hardware: All
OS: Linux
urgent
high
Target Milestone: ---
: 3.4.0
Assignee: Alon Bar-Lev
QA Contact: Jiri Belka
URL:
Whiteboard: integration
Depends On:
Blocks: 1067453 rhev3.4beta 1142926
TreeView+ depends on / blocked
 
Reported: 2014-02-12 15:37 UTC by James W. Mills
Modified: 2018-12-04 17:28 UTC (History)
13 users (show)

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.
Clone Of:
: 1067453 (view as bug list)
Environment:
Last Closed: 2014-06-12 14:04:35 UTC
oVirt Team: ---
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 24407 None None None Never
oVirt gerrit 24451 None None None Never
oVirt gerrit 24460 None None None Never
oVirt gerrit 24461 None None None Never
Red Hat Knowledge Base (Solution) 721433 None None None Never
Red Hat Product Errata RHSA-2014:0506 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Virtualization Manager 3.4.0 update 2014-06-09 18:55:38 UTC

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


Note You need to log in before you can comment on or make changes to this bug.