php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #53217 PDO-pgsql fails to escape backslashes in passwords
Submitted: 2010-11-01 08:04 UTC Modified: 2010-12-04 08:13 UTC
From: bell at ctrlf5 dot co dot za Assigned:
Status: Not a bug Package: PDO related
PHP Version: 5.3.3 OS: Ubuntu 10.04 AMD64 W/S
Private report: No CVE-ID: None
 [2010-11-01 08:04 UTC] bell at ctrlf5 dot co dot za
Description:
------------
When using a password containing a backslash to connect to PostgreSQL database via PDO the driver appears to be treating the backslash as an escape charcter. 

The problem is not global to PDO since MySQL works as expected.

It is not global to libpq since PearDB and the psql command line tool work as expected.

Further explanation in the comments in the test script.

Test script:
---------------
$host = 'localhost';
$database = 'imix';
$username = 'imix';
// Password is |\/|ix3dUp
/*
  Works for MySQL - Doesn't work for pgsql - wireshark shows |/x3edUp sent to server, error message shows password correctly 
*/
$mysql_password = '|\/|ix3dUp';
/*
  Doesn't work for pg - |/x3edUp still sent to server - error message still shows password correctly - this is because \ is one of the two chars escaped in a single quoted string
*/
// $password = '|\\/|ix3dUp';
/*
  Works for pgsql, not for mysql - Error message on mysql attempt shows two backslashes
  Initial parse treats the first one as an escape, handing two to PDO - pgsql driver seems to interpret the first remaining one as an escape which really doesn't sound right ...
*/
$pgsql_password = '|\\\/|ix3dUp';

$mysql_connection = new PDO('mysql:host='.$host.';dbname='.$database, $username, $mysql_password);

$pgsql_connection = new PDO('pgsql:host='.$host.';dbname='.$database, $username, $pgsql_password);


Expected result:
----------------
I would expect the password as used for MySQL to work for both the engines.

Actual result:
--------------
Test script as it stands executes without error.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-11-01 18:24 UTC] felipe@php.net
-Status: Open +Status: Bogus
 [2010-11-01 18:24 UTC] felipe@php.net
This is due the libpq behavior. See http://www.postgresql.org/docs/8.1/static/libpq.html
 [2010-11-01 18:44 UTC] bell at ctrlf5 dot co dot za
So you believe that it is not PDO's responsibility to escape input values before passing them to underlying functions?

That doesn't sound right.
 [2010-11-01 19:19 UTC] felipe@php.net
-Status: Bogus +Status: Open
 [2010-11-01 19:19 UTC] felipe@php.net
Well, I was wondering about the connect string using the password with others parameters, not when using the password on a separated parameter (as in your example). In this case, I guess it could be escaped, as requested.
 [2010-11-25 20:35 UTC] iliaa@php.net
-Status: Open +Status: Bogus
 [2010-11-25 20:35 UTC] iliaa@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php


 [2010-12-04 08:13 UTC] bell at ctrlf5 dot co dot za
-Summary: PDO treats backslashes in pgsql passwords as escape characters +Summary: PDO-pgsql fails to escape backslashes in passwords
 [2010-12-04 08:13 UTC] bell at ctrlf5 dot co dot za
I have read the documentation. I says that the function takes a password as a parameter. As it stands the password needs to be escaped. This is a bug, and a relatively easily addressable one at that.

It would be nice if the maintainer who closed the bug most recently could likewise have read the issue. Any reference to the specifics or merits of the bug would have been preferable to the cut and paste notice. The condescending (and likely sarcastic) "thanks" in the boilerplate fobbing off just makes it all the more annoying.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Tue Mar 02 15:01:24 2021 UTC