DOS-style line endings in .pgpass

On 11/14/2016 08:31 PM, Josh Berkus wrote:

Version Tested: 9.6.1
Platform: Fedora 24 Docker Base Image
Summary: DOS-style line endings (CRLF) cause .pgpass to fail.

Steps to Reproduce:

1. Install PostgreSQL
2. Set up user with md5 passwords
3. Create pgpass file using program which makes CRLF line endings, such
as Python's CSV module, or windows Notepad.
4. Try to log in
5. Get:

psql: FATAL: password authentication failed for user "postgres"
password retrieved from file "/var/lib/pgsql/.pgpass"

What appears to be happening here is that one of the characters of the
CRLF is being appended to the password, making it invalid.

Is this a known issue on Windows? Or is this peculiar to Fedora?

If it's a general issue, it would be friendly to Windows devs to fix it.

Maybe something like the attached patch?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On Mon, Nov 14, 2016 at 1:31 PM, Josh Berkus <josh@agliodbs.com> wrote:

Version Tested: 9.6.1
Platform: Fedora 24 Docker Base Image
Summary: DOS-style line endings (CRLF) cause .pgpass to fail.

Steps to Reproduce:

1. Install PostgreSQL
2. Set up user with md5 passwords
3. Create pgpass file using program which makes CRLF line endings, such
as Python's CSV module, or windows Notepad.
4. Try to log in
5. Get:

psql: FATAL: password authentication failed for user "postgres"
password retrieved from file "/var/lib/pgsql/.pgpass"

What appears to be happening here is that one of the characters of the
CRLF is being appended to the password, making it invalid.

Is this a known issue on Windows? Or is this peculiar to Fedora?

If it's a general issue, it would be friendly to Windows devs to fix it.

​The problem is the Windows line endings. Such a file ends with a CRLF
which is 0x0D0A. When a Linux/UNIX system reads this, the 0x0D is processed
as a data character. So a line like:

*:*:*:user:password

​which has DOS line endings will end up with the last field looking like
"password^M" where ^M is 0x0D.​ The only "solution" that I can think of is
for the PostgreSQL people to put in special code which removes any trailing
0x0D character from the end a a line. Something along the lines of:

fgets(pgpass_line,sizeof pgpass_line,pgpass_fd);
int line_length=length(pgpass_line);
if (pgpass_line[line_length]=0x0D) {
pg_pass_line[line_length]=0x00; /* remove 0x0D from end of line */
line_length--;
}

Likewise, in many cases, if you read a file with UNIX line endings, a
Windows program will no recognize the 0x0A (which a preceeding 0x0D) as an
end-of-line but will use it as a data character and continue reading.
Possibly until the end of the file.

​

--
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

Vik Fearing <vik@2ndquadrant.fr> writes:

On 11/14/2016 08:31 PM, Josh Berkus wrote:

What appears to be happening here is that one of the characters of the
CRLF is being appended to the password, making it invalid.

Maybe something like the attached patch?

Our usual approach to \r characters is that they're whitespace. I wonder
whether the most friendly solution here is to chomp all trailing
whitespace. Anybody ever heard of using a trailing space or tab in a
password?

while (len > 0 && strchr(" \t\r\n", buf[len - 1]) != NULL)
buf[--len] = '\0';

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

On Mon, Nov 14, 2016 at 2:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Vik Fearing <vik@2ndquadrant.fr> writes:

On 11/14/2016 08:31 PM, Josh Berkus wrote:

What appears to be happening here is that one of the characters of the
CRLF is being appended to the password, making it invalid.

Maybe something like the attached patch?

Our usual approach to \r characters is that they're whitespace. I wonder
whether the most friendly solution here is to chomp all trailing
whitespace. Anybody ever heard of using a trailing space or tab in a
password?

while (len > 0 && strchr(" \t\r\n", buf[len - 1]) != NULL)
buf[--len] = '\0';

regards, tom lane

​FWIW, I think that's a really good idea. I, personally, don't like
non-printable characters in passwords. They are harder than <elided> to
enter on the keyboard.​

--
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

On 11/14/2016 09:10 PM, Tom Lane wrote:

Vik Fearing <vik@2ndquadrant.fr> writes:

On 11/14/2016 08:31 PM, Josh Berkus wrote:

What appears to be happening here is that one of the characters of the
CRLF is being appended to the password, making it invalid.

Maybe something like the attached patch?

Our usual approach to \r characters is that they're whitespace. I wonder
whether the most friendly solution here is to chomp all trailing
whitespace. Anybody ever heard of using a trailing space or tab in a
password?

Trailing, no; but I have a password with a space in the middle.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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

Vik Fearing <vik@2ndquadrant.fr> writes:

On 11/14/2016 09:10 PM, Tom Lane wrote:

Our usual approach to \r characters is that they're whitespace. I wonder
whether the most friendly solution here is to chomp all trailing
whitespace. Anybody ever heard of using a trailing space or tab in a
password?

Trailing, no; but I have a password with a space in the middle.

Hm, well, given that we found somebody with an embedded space so
easily, maybe trailing spaces are out there too. Also it strikes me
that we don't strip whitespace from the other fields in .pgpass,
so maybe doing it just for the password isn't so smart.

Let's just chomp \n and then \r, and be done.

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