[pgpool-hackers: 148] Re: [Pgpool-hackers] Reload does not help if password file changed

[Gurjeet Singh]

I understand that this patch was committed on 2011-09-29, and pgpool 3.1
was released on 2011-09-08. So quite possibly the answer to the next
question is no.

Can you please confirm if pgpool 3.1 has this fix?

I am assuming it is fixed in 3.2 for sure.

Just to refresh memory, I am talking about making pgpool pickup changes in
pool_passwd.conf file on reload signal.

Best regards,


On Thu, Sep 29, 2011 at 8:09 AM, Gurjeet Singh <singh.gurjeet at gmail.com>wrote:

> Thanks for the correcting the mistakes. Although I think the stack-frame
> of main() function is always available to all the functions that come after
> it, hence using a stack variable from that frame wouldn't have hurt, but I
> agree with the change because it avoids any future confusion.
>
> Also, would it be possible to back-patch this to previous stable versions?
> As my earlier complaints, I wouldn't treat this as new feature, but a bug
> which always got overlooked, because SIGHUP is always supposed to reload
> the config files and yet password changes were never updated. My 2 cents.
>
> Regards,
>
>
> On Thu, Sep 29, 2011 at 4:47 AM, Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
>
>> Hi Gurjeet,
>>
>> I have committed your patches to CVS HEAD with my minor editings. It's
>> great that we don't need to restart pgpool-II each time user changed
>> md5 password!
>>
>> Here are my slight changes to original patch:
>>
>> - Checking pool_config->pool_passwd is not correct way to judge if we
>>  need to reopen pool_passwd or not. Rather you should look into
>>  enable_pool_hba. Because pool_config->pool_passwd is the base file
>>  name of pool_passwd(can be used if you want to change standard
>>  "pool_passwd"), and md5 auth is not enabled if enable_pool_hba is
>>  off.
>>
>> - Storing pointer to pool_passwd path will not work since the body is
>>  located at a stack area(char pool_passwd[POOLMAXPATHLEN+1] around
>>  line 425 of mainc.). I modify to copy it to static memory.
>>
>> Chinese, French and German doc maintainer:
>>
>> I have modified documentation around line 3279 of
>> pgpool-en.html. Please update other language. Thanks in advance.
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese: http://www.sraoss.co.jp
>>
>> > Hi Gurjeet,
>> >
>> > Sorry for delay.
>> > I will take care of this tomorrow.
>> > --
>> > Tatsuo Ishii
>> > SRA OSS, Inc. Japan
>> > English: http://www.sraoss.co.jp/index_en.php
>> > Japanese: http://www.sraoss.co.jp
>> >
>> >> Hi Tatsuo,
>> >>
>> >>     Any feedback on the correctness of the patch?
>> >>
>> >> Thanks,
>> >>
>> >> On Mon, Sep 26, 2011 at 10:18 PM, Gurjeet Singh <
>> singh.gurjeet at gmail.com>wrote:
>> >>
>> >>> Hi Tatsuo,
>> >>>
>> >>>     Please find an updated patch. I am now using strcmp() to check if
>> we
>> >>> need to reopne the file, just like the code in main.c, instead of
>> comparing
>> >>> the value with NULL.
>> >>>
>> >>> Regards,
>> >>>
>> >>>
>> >>> On Mon, Sep 26, 2011 at 9:57 PM, Tatsuo Ishii <ishii at sraoss.co.jp>
>> wrote:
>> >>>
>> >>>> Thanks for report and patches. I will take care of this.
>> >>>> --
>> >>>> Tatsuo Ishii
>> >>>> SRA OSS, Inc. Japan
>> >>>> English: http://www.sraoss.co.jp/index_en.php
>> >>>> Japanese: http://www.sraoss.co.jp
>> >>>>
>> >>>> > Hi,
>> >>>> >
>> >>>> >     Maybe this is expected behaviour, but it definitely is not
>> >>>> desirable. If
>> >>>> > we add a new user:passwrod to the contents of pool_passwd file and
>> send
>> >>>> a
>> >>>> > reload signal to pgpool, the child processes are still not able to
>> honor
>> >>>> the
>> >>>> > new user and the trying to login using the new user causes error
>> "MD5
>> >>>> > authentication failed..."
>> >>>> >
>> >>>> >     I have diagnosed it back to the fact that pgpool uses stdio.h
>> >>>> interface
>> >>>> > (FILE *) to access the pool_passwd file, and it reads the contents
>> of
>> >>>> the
>> >>>> > file for every new login that requests MD5 authentication. The
>> problem
>> >>>> with
>> >>>> > the stdio.h interface is that it caches the contents of the file
>> and it
>> >>>> does
>> >>>> > not refresh the cache even when the contents of the file change
>> on-disk,
>> >>>> so
>> >>>> > every time pgpool tries to read new user's password it does not
>> see the
>> >>>> new
>> >>>> > entry and hence fails.
>> >>>> >
>> >>>> >     To be able to connect as the new user we have to either restart
>> >>>> pgpool
>> >>>> > or wait for a new child to be forked which will see the new
>> contents of
>> >>>> the
>> >>>> > file. All of these problems also apply to the case where we might
>> alter
>> >>>> the
>> >>>> > password of an existing user and update the md5 password in
>> pool_passwd
>> >>>> > file.
>> >>>> >
>> >>>> >     I have attached a minimal patch to address this issue. In the
>> patch,
>> >>>> we
>> >>>> > save the file path that was initially used to open the pool_passwd
>> and
>> >>>> upon
>> >>>> > every reload the child closes and reopens the file so that the
>> stdio.h
>> >>>> > interface does not show it cached data.
>> >>>> >
>> >>>> > Regards,
>> >>>> > --
>> >>>> > Gurjeet Singh
>> >>>> > EnterpriseDB Corporation
>> >>>> > The Enterprise PostgreSQL Company
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Gurjeet Singh
>> >>> EnterpriseDB Corporation
>> >>> The Enterprise PostgreSQL Company
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Gurjeet Singh
>> >> EnterpriseDB Corporation
>> >> The Enterprise PostgreSQL Company
>> > _______________________________________________
>> > Pgpool-hackers mailing list
>> > Pgpool-hackers at pgfoundry.org
>> > http://pgfoundry.org/mailman/listinfo/pgpool-hackers
>>
>
>
>
> --
> Gurjeet Singh
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
>


-- 
Gurjeet Singh

http://gurjeet.singh.im/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20121101/373f3847/attachment.html>