Thread: BUG #7514: postgres -k no longer works with spaces in the path

The following bug has been logged on the website:

Bug reference:      7514
Logged by:          Murray Cumming
Email address:      murrayc@murrayc.com
PostgreSQL version: 9.1.5
Operating system:   Fedora Linux 17
Description:        =


At some point, probably in 9.1.5, the -k option to Postgres ("Unix-domain
socket location" in --help), stopped accepting paths that contain spaces.

For instance,
-k '/tmp/testglom2FPDKW/path with spaces/some_postgres_data'

It now fails with this error:
FATAL:  invalid list syntax for "unix_socket_directories"

This is not critical, but it showed up in the regression tests for Glom. And
users are fairly likely to use paths with spaces.

-k apparently accepts a comma-separated list, so there should be no need to
check for spaces.

murrayc@murrayc.com writes:
> At some point, probably in 9.1.5, the -k option to Postgres ("Unix-domain
> socket location" in --help), stopped accepting paths that contain spaces.

> For instance,
> -k '/tmp/testglom2FPDKW/path with spaces/some_postgres_data'

> It now fails with this error:
> FATAL:  invalid list syntax for "unix_socket_directories"

Ah, you're using the latest Fedora packaging of 9.1.x, which includes a
back-ported version of the unix_socket_directories change that's in
HEAD.  -k now effectively takes a list of directory names, not just
one, and it's pickier about whitespace.

IIRC, you can make it work if you put double quotes around the
space-containing name, so it'd look like this:

    -k '"/blah blah blah"'


            regards, tom lane

On Tue, 2012-09-04 at 10:31 -0400, Tom Lane wrote:
> murrayc@murrayc.com writes:
> > At some point, probably in 9.1.5, the -k option to Postgres ("Unix-domain
> > socket location" in --help), stopped accepting paths that contain spaces.
>
> > For instance,
> > -k '/tmp/testglom2FPDKW/path with spaces/some_postgres_data'
>
> > It now fails with this error:
> > FATAL:  invalid list syntax for "unix_socket_directories"
>
> Ah, you're using the latest Fedora packaging of 9.1.x, which includes a
> back-ported version of the unix_socket_directories change that's in
> HEAD.  -k now effectively takes a list of directory names, not just
> one, and it's pickier about whitespace.
>
> IIRC, you can make it work if you put double quotes around the
> space-containing name, so it'd look like this:
>
>     -k '"/blah blah blah"'

Yes, thanks, that works for spaces, though it's rather odd.

However, how should I now specify a path that has a " or a /, or \,
which now cause similar errors with -k? Previously I could just use
g_shell_quote() and forget about it:
http://developer.gnome.org/glib/stable/glib-Shell-related-Utilities.html#g-shell-quote

To be honest, I don't have much interest in, or understanding of, this
-k option anyway. I just use it because, when starting my temporary
postgresql instance, it otherwise defaults to /var/run/postgresql/ (at
least in this distro build) which is not available to normal users. I
currently just specify the same directory that the postgresql data is
in. Maybe I should just use /tmp instead.

--
murrayc@murrayc.com
www.murrayc.com
www.openismus.com

On 9/4/12 2:22 PM, Murray Cumming wrote:
> On Tue, 2012-09-04 at 10:31 -0400, Tom Lane wrote:
>> murrayc@murrayc.com writes:
>>> At some point, probably in 9.1.5, the -k option to Postgres ("Unix-domain
>>> socket location" in --help), stopped accepting paths that contain spaces.
>>
>>> For instance,
>>> -k '/tmp/testglom2FPDKW/path with spaces/some_postgres_data'
>>
>>> It now fails with this error:
>>> FATAL:  invalid list syntax for "unix_socket_directories"
>>
>> Ah, you're using the latest Fedora packaging of 9.1.x, which includes a
>> back-ported version of the unix_socket_directories change that's in
>> HEAD.  -k now effectively takes a list of directory names, not just
>> one, and it's pickier about whitespace.
>>
>> IIRC, you can make it work if you put double quotes around the
>> space-containing name, so it'd look like this:
>>
>>     -k '"/blah blah blah"'
>
> Yes, thanks, that works for spaces, though it's rather odd.
>
> However, how should I now specify a path that has a " or a /, or \,
> which now cause similar errors with -k? Previously I could just use
> g_shell_quote() and forget about it:
> http://developer.gnome.org/glib/stable/glib-Shell-related-Utilities.html#g-shell-quote
>
> To be honest, I don't have much interest in, or understanding of, this
> -k option anyway. I just use it because, when starting my temporary
> postgresql instance, it otherwise defaults to /var/run/postgresql/ (at
> least in this distro build) which is not available to normal users. I
> currently just specify the same directory that the postgresql data is
> in. Maybe I should just use /tmp instead.

Maybe it would be easier if multiple -k options accumulated.  That would
make the whole quoting business easier, and it would avoid breaking
compatibility.

Peter Eisentraut <peter_e@gmx.net> writes:
> Maybe it would be easier if multiple -k options accumulated.

Hm, interesting thought, but how would we make that play in the generic
GUC support?  Or are you imagining that we'd just kluge up -k with some
single-purpose code?

            regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:
> Maybe it would be easier if multiple -k options accumulated.

After further thought I'm not very enamored of that concept.  We've made
considerable compromises to ensure that every postmaster command-line
option corresponds exactly to some GUC parameter; it does not seem to me
that -k is important enough to deserve an exception.

However, it occurs to me that Murray's original complaint about spaces
in -k pathnames could be dealt with via very narrow changes in
SplitDirectoriesString.  That function was modeled on
SplitIdentifierString, with perhaps not enough thought about the
differences between identifiers and pathnames.  In particular, I suggest
that there's no need to reject embedded spaces in pathnames, and plenty
of systems on which it's important not to.  (Think "Program Files" on
Windows, for instance.)  It probably still makes sense to trim leading
and trailing whitespace, but let's allow embedded spaces.

If we did that, the new code would be incompatible with the old only for
paths including commas, leading double quotes, or leading/trailing
whitespace.  I submit that all of those cases are pretty uncommon,
especially compared to embedded space.

            regards, tom lane

On Wed, Sep 5, 2012 at 8:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> Maybe it would be easier if multiple -k options accumulated.
>
> After further thought I'm not very enamored of that concept.  We've made
> considerable compromises to ensure that every postmaster command-line
> option corresponds exactly to some GUC parameter; it does not seem to me
> that -k is important enough to deserve an exception.
>
> However, it occurs to me that Murray's original complaint about spaces
> in -k pathnames could be dealt with via very narrow changes in
> SplitDirectoriesString.  That function was modeled on
> SplitIdentifierString, with perhaps not enough thought about the
> differences between identifiers and pathnames.  In particular, I suggest
> that there's no need to reject embedded spaces in pathnames, and plenty
> of systems on which it's important not to.  (Think "Program Files" on
> Windows, for instance.)  It probably still makes sense to trim leading
> and trailing whitespace, but let's allow embedded spaces.
>
> If we did that, the new code would be incompatible with the old only for
> paths including commas, leading double quotes, or leading/trailing
> whitespace.  I submit that all of those cases are pretty uncommon,
> especially compared to embedded space.

That seems reasonable.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, 2012-09-04 at 20:22 +0200, Murray Cumming wrote:
> To be honest, I don't have much interest in, or understanding of, this
> -k option anyway. I just use it because, when starting my temporary
> postgresql instance, it otherwise defaults to /var/run/postgresql/ (at
> least in this distro build) which is not available to normal users. I
> currently just specify the same directory that the postgresql data is
> in. Maybe I should just use /tmp instead.

Or would that be a security hole, allowing other users to access the
database server on multiuser systems?

--
Murray Cumming
murrayc@murrayc.com
www.murrayc.com
www.openismus.com