Thread: BUG #1580: pg_dumpall aborts when cwd is unreadable

BUG #1580: pg_dumpall aborts when cwd is unreadable

From
"David Elliott"
Date:
The following bug has been logged online:

Bug reference:      1580
Logged by:          David Elliott
Email address:      elliott@stcnet.com
PostgreSQL version: 8.0.1
Operating system:   Mac OS X 10.3.8
Description:        pg_dumpall aborts when cwd is unreadable
Details:

After setting up a cron job to backup the database nightly I noticed it
wasn't running.  The log contained the following messages:

could not identify current directory: Permission denied
could not identify current directory: Permission denied
could not identify current directory: Permission denied
The program "pg_dump" is needed by pg_dumpall but was not found in the
same directory as "pg_dumpall".
Check your installation.

It can be reproduced quite simply on the command-line.  As root and with
CWD= root's home directory (not readable by anyone but root) do this:
# sudo -u postgres /usr/local/pgsql/bin/pg_dumpall

Changing to a path readable by the postgres user before running the command
fixes the issue.

When an absolute path is given I see no reason to read the current directory
before trying the absolute path.

Re: BUG #1580: pg_dumpall aborts when cwd is unreadable

From
Bruce Momjian
Date:
David Elliott wrote:
>
> The following bug has been logged online:
>
> Bug reference:      1580
> Logged by:          David Elliott
> Email address:      elliott@stcnet.com
> PostgreSQL version: 8.0.1
> Operating system:   Mac OS X 10.3.8
> Description:        pg_dumpall aborts when cwd is unreadable
> Details:
>
> After setting up a cron job to backup the database nightly I noticed it
> wasn't running.  The log contained the following messages:
>
> could not identify current directory: Permission denied
> could not identify current directory: Permission denied
> could not identify current directory: Permission denied
> The program "pg_dump" is needed by pg_dumpall but was not found in the
> same directory as "pg_dumpall".
> Check your installation.
>
> It can be reproduced quite simply on the command-line.  As root and with
> CWD= root's home directory (not readable by anyone but root) do this:
> # sudo -u postgres /usr/local/pgsql/bin/pg_dumpall
>
> Changing to a path readable by the postgres user before running the command
> fixes the issue.
>
> When an absolute path is given I see no reason to read the current directory
> before trying the absolute path.

The reason this happens is because pg_dumpall has to be sure it can find
pg_dump, and that pg_dump is the same PostgreSQL version as pg_dumpall.

While we could do this without knowing the current directory, the code
is easier if we know it.  If you look in find_my_exec() in
src/port/exec.c you can see what we use 'cwd' for.  It is used if the
PATH contains the current directory, and on Win32 which checks the
current directory first.

The code right now tests for 'cwd' first and just errors out if it can't
find it.  Is it worth refactoring it so you can run pg_dumpall from a
directory you can't view?  Instead of checking 'cwd' right at the start
we would have to find it only when we need it, and in several places or
in a function call.  It doesn't seem worth it to me.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: BUG #1580: pg_dumpall aborts when cwd is unreadable

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The code right now tests for 'cwd' first and just errors out if it can't
> find it.  Is it worth refactoring it so you can run pg_dumpall from a
> directory you can't view?  Instead of checking 'cwd' right at the start
> we would have to find it only when we need it, and in several places or
> in a function call.  It doesn't seem worth it to me.

... and it would *still* fail if you tried to call pg_dumpall via a
symlink or relative path.  Unless someone knows a portable way to
resolve symlinks without doing a chdir first, I think there's no
way to avoid the surprise factor.

            regards, tom lane