Bug 443223 - Tablespace creation failure: could not set permissions on directory
Tablespace creation failure: could not set permissions on directory
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: postgresql (Show other bugs)
5.3
All Linux
low Severity low
: rc
: ---
Assigned To: Tom Lane
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-19 08:54 EDT by Graham Leggett
Modified: 2013-07-02 23:17 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-19 12:30:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Graham Leggett 2008-04-19 08:54:40 EDT
When an attempt is made to create a tablespace, where the tablespace directory
exists, the ownership is correct, and the permissions have been correctly set to
0700, and SELinux is *disabled*, the following error occurs:

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

The problem comes down to the following piece of code within postgres, which
incorrectly tries to set the permissions on the tablespace directory to 0700.
What the code is trying to do is to ensure the permissions are set to 0700 by
setting the permissions to 0700. What the code should be doing is testing that
the permissions are 0700, and throwing an error if this is not the case.

This saves the admin going on a wild goose chase trying to work out why the
postgres user cannot chmod a directory owned by the postgres user to 0700, when
the permissions are already correctly set in the first place.

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)));
Comment 1 Tom Lane 2008-04-19 11:04:08 EDT
As the comment says, the chmod should succeed if the directory is both accessible to and owned by the 
postgres user; and if either of those conditions doesn't hold, we can't use the directory anyway.  (I suspect 
the failure in this case was because some upper-level directory in the path had the wrong permissions.)  
So I see no bug here.  If you can point out a real-world case where the chmod wouldn't work and yet it'd 
be all right to use the directory, I might reconsider.
Comment 2 Graham Leggett 2008-04-19 11:32:57 EDT
As it turned out, the postgresql server had cached permission credentials, so
while the postgres user could see the directory without a problem, this was not
possible by postgresql until the server could be restarted from scratch.

Going off to Google found a number of hits about it not being possible to chmod
a directory if you are not the superuser under certain, and with the addition of
SELinux the wild goose chase was assured.

Ideally the error message should suggest that the server might need to be
restarted before the permissions take effect.
Comment 3 Tom Lane 2008-04-19 12:30:04 EDT
Per the concurrent discussion in pgsql-admin, there is no obvious reason why a restart would help.  I 
think you might possibly have a reason to file a kernel bug here, but it's not a postgres bug.

Note You need to log in before you can comment on or make changes to this bug.