[pgpool-hackers: 2999] Re: Pgpool-II 4.0 alpha2 show-stoppers
ishii at sraoss.co.jp
Mon Aug 27 11:22:05 JST 2018
If you agree on adding "TEXT" prefix to clear text passwords, when
will you finish to implement it? Hoshiai wants to fix bug 419 on
master branch after you implement it.
SRA OSS, Inc. Japan
From: Tatsuo Ishii <ishii at sraoss.co.jp>
Subject: [pgpool-hackers: 2996] Re: Pgpool-II 4.0 alpha2 show-stoppers
Date: Mon, 27 Aug 2018 10:40:06 +0900 (JST)
Message-ID: <20180827.104006.943557284970723125.t-ishii at sraoss.co.jp>
>> On Fri, Aug 24, 2018 at 10:34 AM Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
>>> > Here are items we need to resolve before going to alpha2.
>>> > 1) 0000425: pgpool_setup don't work with pre PostgreSQL 10.
>>> > - https://www.pgpool.net/mantisbt/view.php?id=425
>>> > - Tatsuo already pushed fix. Let's see if buildfarm complains.
>>> > 2) 0000426: Pgpool-II contines to emit warning messages
>>> > - https://www.pgpool.net/mantisbt/view.php?id=426
>>> I have looked into this a little bit. It turns out that the
>>> specification for all "password" entries (health check streaming
>>> replication delay check, at least) in the pgpool.conf has been changed
>>> since 4.0. From the 4.0 manual:
>>> If health_check_password is left blank Pgpool-II will first try to
>>> get the password for health_check_user from pool_passwd file before
>>> using the empty password.
>>> You can also specify AES256-CBC encrypted password in
>>> health_check_password field. To specify the AES encrypted password,
>>> password string must be prefixed with AES after encrypting (using
>>> aes-256-cbc algorithm) and encoding to base64.
>>> Since pgpool_setup left password blank (actually not blank, but empty
>>> string), Pgpool-II tries to retrieve health_check_user, for example,
>>> from pool_passwd. But since pool_enable_hba = off, no entry for the
>>> user found in pgpool_passwd. I think this behavior is strange, since
>>> pool_passwd should only be consulted when pool_enable_hba is on.
>> Yes as part of SCRAM feature I try to solve all unsecure password storages
>> by Pgpool-II, and for that I think the pool_passwd file is the best option
>> of using a new file. Because we can continue to evolve the pool_passwd in
>> and as a result every module in Pgpool-II that uses the password will
>> benefit from it.
>> Is there any specific reason why we want to disable pool_passwd consulting
>> pool_enable_hba is off ?
> Ok, besides backward compatibility breaking, I think there's no reason
> we need to stop looking up pool_passwd if pool_enable_hba is off. In
> this we need to carefully explain to users who want to migrate to 4.0.
> Probably we need to have "incompatibility" section in the release
>>> Also I have to point out "password string must be prefixed with AES
>>> after encrypting" is questionable spec. Since people could enter any
>>> clear text password including prefixed with AES, there's no way to
>>> determine if it is a clear text password or AES encrypted. If we want
>>> to store AES encrypted password, then there should be a configuration
>>> parameter which specifies the password format (encrypted in AES or
>>> Without the flag, the design looks too hacky.
>> Yes thats a valid point, and I think we can have two options if we want to
>> text passwords in pool_passwd.
>> 1- Use TEXT prefix for text password similarly to AES and MD5
>> 2- Use escape character to escape AES and MD5 prefixes.
> I think "TEXT prefix" is a good idea, because it's easy to understand
> for users and easy to implement than having new switches. But again,
> this clearly breaks backward compatibilty and should be warned loudly
> in the release note. Also we need to reject password entry which does
> not have none of MD5, AES or TEXT prefix. If the case, what should we
> do? We need to check the behavior of 4.0.
> For a record, I list up items in pgpool.conf which is affected by the
> changes in 4.0.
>>> Note that I pointed out similar thing regarding pool_passwd. I
>>> objected to include clear text password in pool_passwd for the same
>>> reason above.
>> Yes we can disallow storing the clear text passwords in pool_passwd but I
>> think as long
>> as we allow the encrypted passwords in the pool_passwd its no harm to a
>> allow text passwords.
> Same thing can be said to the password in pgpool.conf.
>> Best Regards
>> Muhammad Usama
>>> > 3) 0000427: pg_enc emits wrong warnings
>>> > - https://www.pgpool.net/mantisbt/view.php?id=427
>>> > 4) Covery errors (mostly memory leaks)
>>> > - Usama is working on it.
>>> > 5) Clear text password should not be allowed in pool_passwd
>>> > 6) Cert auth does not work between client and Pgpool-II
>>> > Please add items if I missed something.
>>> > --
>>> > Tatsuo Ishii
>>> > SRA OSS, Inc. Japan
>>> > English: http://www.sraoss.co.jp/index_en.php
>>> > Japanese:http://www.sraoss.co.jp
>>> > _______________________________________________
>>> > pgpool-hackers mailing list
>>> > pgpool-hackers at pgpool.net
>>> > http://www.pgpool.net/mailman/listinfo/pgpool-hackers
>>> pgpool-hackers mailing list
>>> pgpool-hackers at pgpool.net
> pgpool-hackers mailing list
> pgpool-hackers at pgpool.net
More information about the pgpool-hackers