Thread: BUG #4116: Cannot create tablespace: could not set permissions on directory

The following bug has been logged online:

Bug reference:      4116
Logged by:          Graham Leggett
Email address:      minfrin@sharp.fm
PostgreSQL version: 8.1.11
Operating system:   Redhat Enterprise 5
Description:        Cannot create tablespace: could not set permissions on
directory
Details:

While making an attempt to create a tablespace, where the tablespace
directory has already been created, has the correct ownership, and has the
correct permissions (0700), the attempt will fail regardless:

postgres=# CREATE TABLESPACE fma LOCATION '/home/fma/db/pgsql';
ERROR:  could not set permissions on directory "/home/fma/db/pgsql":
Permission denied

Looking in the source, the error message "could not set permissions on
directory" appears here:

01283         /*
01284          * Attempt to coerce target directory to safe permissions.  If
this
01285          * fails, it doesn't exist or has the wrong owner.
01286          */
01287         if (chmod(location, 0700) != 0)
01288             ereport(ERROR,
01289                     (errcode_for_file_access(),
01290                   errmsg("could not set permissions on directory
\"%s\": %m",
01291                          location)));

This code makes the incorrect assumption that the platform will allow the
postgres user to set the permissions using chmod.

What this code should be doing is checking that the permissions on the
directory are 0700, and failing if they are not, leaving it up to the user
to fix the problem.

Redhat Enterprise Linux 5 refuses to allow a user to chmod a directory, even
though that user owns that directory. In addition, if SELinux is enabled,
this gives a further reason why the code will fail.

To fix this, check that the mode is 0700, don't try to set it.

Graham Leggett wrote:

> This code makes the incorrect assumption that the platform will allow the
> postgres user to set the permissions using chmod.

> What this code should be doing is checking that the permissions on the
> directory are 0700, and failing if they are not, leaving it up to the user
> to fix the problem.
>
> Redhat Enterprise Linux 5 refuses to allow a user to chmod a directory, even
> though that user owns that directory. In addition, if SELinux is enabled,
> this gives a further reason why the code will fail.

Is this something we should do anything about?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Graham Leggett wrote:
>> This code makes the incorrect assumption that the platform will allow the
>> postgres user to set the permissions using chmod.

> Is this something we should do anything about?

IMHO, no.  The reason for actually doing the chmod is to verify that we
own the directory.  If it fails, we don't own the directory in any
meaningful sense.  I think the complainant's real problem is that he's
misconfigured his SELinux permissions.

            regards, tom lane

Tom Lane wrote:

>>> This code makes the incorrect assumption that the platform will allow the
>>> postgres user to set the permissions using chmod.
>
>> Is this something we should do anything about?
>
> IMHO, no.  The reason for actually doing the chmod is to verify that we
> own the directory.  If it fails, we don't own the directory in any
> meaningful sense.  I think the complainant's real problem is that he's
> misconfigured his SELinux permissions.

I'm afraid the machine came with SELinux permissions pre-misconfigured
for me, and postgres didn't help the situation at all by sending me on a
wild goose chase.

The correct way to check the permissions are correct is by testing the
current permission values against what they should be, and then failing
clearly and explicitly with a meaningful error message. Right now the
code takes a short cut, which is easy for the coder, but very painful
for the long suffering administrator.

Regards,
Graham
--