Thread: [BUGS] BUG #14859: Config file parsing is allergic to spaces on last line offile

The following bug has been logged on the website:

Bug reference:      14859
Logged by:          Mark Jones
Email address:      boatcoder@gmail.com
PostgreSQL version: 9.5.9
Operating system:   Ubuntu
Description:

Edit your pg_hba.conf file, add a space (without a new line) at the end of
the file.

Attempt to start postgres.  It will fail with messages like this.

2017-10-17 13:20:22 UTC [2471-1] LOG:  invalid connection type "ost"
2017-10-17 13:20:22 UTC [2471-2] CONTEXT:  line 103 of configuration file
"/etc/postgresql/9.5/main/pg_hba.conf"
2017-10-17 13:20:22 UTC [2471-3] FATAL:  could not load pg_hba.conf

Look at config file file, scratch head because space is hard to
detect.....
Finally figure it out.  Wonder how that space got in there....


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

boatcoder@gmail.com writes:
> Edit your pg_hba.conf file, add a space (without a new line) at the end of
> the file.
> Attempt to start postgres.  It will fail with messages like this.

Hmph.  I can reproduce this in 9.6 and earlier, but not in v10 or HEAD.
Apparently somebody fixed it by accident.  Looking ...
        regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Tue, Oct 17, 2017 at 7:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmph.  I can reproduce this in 9.6 and earlier, but not in v10 or HEAD.
>> Apparently somebody fixed it by accident.  Looking ...

> ​Probably as a side-effect of:
> "​Add view pg_hba_file_rules to display the contents of pg_hba.conf"
> to v10 (you can probably find the commit hash faster than I).

Close, but apparently it was the adjacent commit 1e5a5d03d,
"Simplify some long-obsolete code in hba.c's next_token()."
in which I wrote
   Also, ensure that we don't return with *lineptr set to someplace past the   terminating '\0'; that would be
catastrophicif a caller were to ask for   another token from the same line.  This is just latent since no callers
actuallydo call again after a "false" return; but considering that it was   actually costing us extra code to do it
wrong,we might as well make it   bulletproof.
 

I was wrong to think that the problem was only latent, because
tokenize_file() decides whether there's more on the line using
    while (strlen(lineptr) > 0)

so that having advanced lineptr past the current line's '\0' allows
it to see (and process) whatever had been in the buffer beyond that
from preceding line(s).

This seems to have been broken since 9.3; kinda surprising nobody
noticed earlier.  I shall go back-patch 1e5a5d03d --- it does a bit
more than the minimum needed to fix the bug, but the other changes
seem harmless enough.
        regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs