Allow continuations in "pg_hba.conf" files

Hi,

On Wed, Mar 25, 2020 at 07:09:38PM +0100, Fabien COELHO wrote:

Hello,

After writing an unreadable and stupidly long line for ldap authentification
in a "pg_hba.conf" file, I figured out that allowing continuations looked
simple enough and should just be done.

I tried this briefly.

-   Records cannot be continued across lines.
+   Records can be backslash-continued across lines.

Maybe say: "lines ending with a backslash are logically continued on the next
line", or similar.

+			/* else we have a continuation, just blank it and loop */
+			continuations++;
+			*curend++ = ' ';

Since it puts a blank there, it creates a "word" boundary, which I gather
worked for your use case. But I wonder whether it's needed to add a space (or
otherwise, document that lines cannot be split beween words?).

You might compare this behavior with that of makefiles (or find a better
example) which I happen to recall *don't* add a space; if you want that, you
have to end the line with: " \" not just "\".

Anyway, I checked that the current patch handles users split across lines, like:
alice,\
bob,\
carol

As written, that depends on the parser's behavior of ignoring commas and
blanks, since it sees:
"alice,[SPACE]bob,[SPACE]carol"

Maybe it'd be nice to avoid depending on that.

I tried with a username called "alice,bob", split across lines:

"alice,\
bob",\

But then your patch makes it look for a user called "alice, bob" (with a
space). I realize that's not a compelling argument :)

Note, that also appears to affect the "username maps" file. So mention in that
chapter, too.
https://www.postgresql.org/docs/current/auth-username-maps.html

Cheers,
--
Justin

Hello Justin,

thanks for the feedback.

-   Records cannot be continued across lines.
+   Records can be backslash-continued across lines.

Maybe say: "lines ending with a backslash are logically continued on the next
line", or similar.

I tried to change it along that.

Since it puts a blank there, it creates a "word" boundary, which I gather
worked for your use case. But I wonder whether it's needed to add a space (or
otherwise, document that lines cannot be split beween words?).

Hmmm. Ok, you are right. I hesitated while doing it. I removed the char
instead, so that it does not add a word break.

Note, that also appears to affect the "username maps" file. So mention
in that chapter, too.
https://www.postgresql.org/docs/current/auth-username-maps.html

Indeed, the same tokenizer is used. I updated a sentence to point on
continuations.

--
Fabien.

Hi Fabien,
Should we consider the case "\ ", i.e. one or more spaces after the backslash?
For example, if I replace a user map
"mymap /^(.*)@mydomain\.com$ \1" with
"mymap /^(.*)@mydomain\.com$ \ "
"\1"
by adding one extra space after the backslash, then I got the pg_role="\\"
but I think what we expect is pg_role="\\1"

At Thu, 02 Apr 2020 00:20:12 +0000, David Zhang <david.zhang@highgo.ca> wrote in

Hi Fabien,
Should we consider the case "\ ", i.e. one or more spaces after the backslash?
For example, if I replace a user map
"mymap /^(.*)@mydomain\.com$ \1" with
"mymap /^(.*)@mydomain\.com$ \ "
"\1"
by adding one extra space after the backslash, then I got the pg_role="\\"
but I think what we expect is pg_role="\\1"

FWIW, I don't think so. Generally a trailing backspace is an escape
character for the following newline. And '\ ' is a escaped space,
which is usualy menas a space itself.

In this case escape character doesn't work generally and I think it is
natural that a backslash in the middle of a line is a backslash
character itself.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Hello,

FWIW, I don't think so. Generally a trailing backspace is an escape
character for the following newline. And '\ ' is a escaped space,
which is usualy menas a space itself.

In this case escape character doesn't work generally and I think it is
natural that a backslash in the middle of a line is a backslash
character itself.

I concur: The backslash char is only a continuation as the very last
character of the line, before cr/nl line ending markers.

There are no assumption about backslash escaping, quotes and such, which
seems reasonable given the lexing structure of the files, i.e. records of
space-separated words, and # line comments.

--
Fabien.

On Thu, Apr 02, 2020 at 07:25:36AM +0200, Fabien COELHO wrote:

Hello,

FWIW, I don't think so. Generally a trailing backspace is an escape
character for the following newline. And '\ ' is a escaped space,
which is usualy menas a space itself.

In this case escape character doesn't work generally and I think it is
natural that a backslash in the middle of a line is a backslash
character itself.

I concur: The backslash char is only a continuation as the very last
character of the line, before cr/nl line ending markers.

There are no assumption about backslash escaping, quotes and such, which
seems reasonable given the lexing structure of the files, i.e. records of
space-separated words, and # line comments.

Quoting does allow words containing spaces:

https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
|A record is made up of a number of fields which are separated by spaces and/or
|tabs. Fields can contain white space if the field value is double-quoted.
|Quoting one of the keywords in a database, user, or address field (e.g., all or
|replication) makes the word lose its special meaning, and just match a
|database, user, or host with that name.

--
Justin

Hi Justin,

There are no assumption about backslash escaping, quotes and such, which
seems reasonable given the lexing structure of the files, i.e. records of
space-separated words, and # line comments.

Quoting does allow words containing spaces:

Ok.

I meant that the continuation handling does not care of that, i.e. if the
continuation is within quotes, then the quoted stuff is implicitely
continuated, there is no different rule because it is within quotes.

--
Fabien.

On 2020-04-01 10:25 p.m., Fabien COELHO wrote:

Hello,

FWIW, I don't think so. Generally a trailing backspace is an escape
character for the following newline.  And '\ ' is a escaped space,
which is usualy menas a space itself.

In this case escape character doesn't work generally and I think it
is natural that a backslash in the middle of a line is a backslash
character itself.

I concur: The backslash char is only a continuation as the very last
character of the line, before cr/nl line ending markers.

+Agree. However, it would nice to update the sentence below if I
understand it correctly.

"+   Comments, whitespace and continuations are handled in the same way
as in" pg_hba.conf

For example, if a user provide a configuration like below (even such a
comments is not recommended)

"host    all     all     127.0.0.1/32    trust  #COMMENTS, it works"

i.e. the original pg_hba.conf allows to have comments in each line, but
with new continuation introduced, the comments has to be put to the last
line.

There are no assumption about backslash escaping, quotes and such,
which seems reasonable given the lexing structure of the files, i.e.
records of space-separated words, and # line comments.

--
David

Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca

Hello David,

+Agree. However, it would nice to update the sentence below if I understand
it correctly.

"+   Comments, whitespace and continuations are handled in the same way as
in" pg_hba.conf

In the attached v3, I've tried to clarify comments and doc about
tokenization rules relating to comments, strings and continuations.

--
Fabien.

In the attached v3, I've tried to clarify comments and doc about tokenization
rules relating to comments, strings and continuations.

Attached v4 improves comments & doc as suggested by Justin.

--
Fabien.

Fabien COELHO <coelho@cri.ensmp.fr> writes:

[ pg-hba-cont-4.patch ]

I looked this over and I think it seems reasonable, but there's
something else we should do. If people are writing lines long
enough that they need to continue them, how long will it be
before they overrun the line length limit? Admittedly, there's
a good deal of daylight between 80 characters and 8K, but if
we're busy removing restrictions on password length in an adjacent
thread [1]/messages/by-id/09512C4F-8CB9-4021-B455-EF4C4F0D55A0@amazon.com, I think we ought to get rid of pg_hba.conf's line length
restriction while we're at it.

Accordingly, I borrowed some code from that thread and present
the attached revision. I also added some test coverage, since
that was lacking before, and wordsmithed docs and comments slightly.

regards, tom lane

[1]: /messages/by-id/09512C4F-8CB9-4021-B455-EF4C4F0D55A0@amazon.com

I wrote:

Accordingly, I borrowed some code from that thread and present
the attached revision. I also added some test coverage, since
that was lacking before, and wordsmithed docs and comments slightly.

Hearing no comments, pushed that way.

regards, tom lane

Hello Tom,

Accordingly, I borrowed some code from that thread and present
the attached revision. I also added some test coverage, since
that was lacking before, and wordsmithed docs and comments slightly.

Hearing no comments, pushed that way.

Thanks for the fixes and improvements!

I notice that buf.data is not freed. I guess that the server memory
management will recover it.

--
Fabien.

Fabien COELHO <coelho@cri.ensmp.fr> writes:

I notice that buf.data is not freed. I guess that the server memory
management will recover it.

Yeah, it's in the transient context holding all of the results of
reading the file. I considered pfree'ing it at the end of the
function, but I concluded there's no point. The space will be
recycled when the context is destroyed, and since we're not (IIRC)
going to allocate anything more in that context, nothing would be
gained by freeing it earlier --- it'd just stay as unused memory
within the context.

regards, tom lane