Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 972425 - postgresql-setup initdb does not work if umask=0077 and /var/lib/pgsql is removed
postgresql-setup initdb does not work if umask=0077 and /var/lib/pgsql is rem...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: postgresql (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Pavel Raiskup
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-09 06:15 EDT by Alon Bar-Lev
Modified: 2016-01-04 00:36 EST (History)
5 users (show)

See Also:
Fixed In Version: postgresql-9.2.5-1.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-28 23:40:48 EDT
Type: Bug
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 Alon Bar-Lev 2013-06-09 06:15:33 EDT
DESCRIPTION

The script issues mkdir -p but changes the permissions and ownership only to end directory resulting the base directory to be inaccessible to postgresql user.

I know that the rpm package contains the base directory, but people tend to remove this as well when cleaning up the databases.

Feel free to close it as WONTFIX, but maybe you would like to fix that.

Minimum fix is not to use mkdir -p and have early failure.

REPRODUCE

# rm -fr /var/lib/pgsql/
# /usr/bin/postgresql-setup initdb
Initializing database ... failed, see /var/lib/pgsql/initdb.log
# cat /var/lib/pgsql/initdb.log
runuser: warning: cannot change directory to /var/lib/pgsql: Permission denied
-bash: /var/lib/pgsql/.bash_profile: Permission denied
could not change directory to "/root"
initdb: could not access directory "/var/lib/pgsql/data": Permission denied
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Comment 1 Tom Lane 2013-06-09 11:10:20 EDT
There's no way that the initdb script can fully recover from somebody doing "rm -rf /var/lib/pgsql".  At the very least, that will blow away the postgres user's .bash_profile; and he may very well have had other files in there too, since it's his home directory.  I don't think we'd be doing anybody a service by making it look like that is supposed to be a supported way to remove the data directory.

IMO, if you delete files that were installed by a package, you should expect to have to reinstall the package to recover from that.
Comment 2 Alon Bar-Lev 2013-06-09 12:29:05 EDT
Thanks tom, the inidb can recover, it does... as the postgresql-setup actually creates that directory, initdb does not mind .bash_profile or any other variable within $HOME of postgres.

If you think it should not recover, I suggest to replace the mkdir -p in this script with test of $(dirname $PGDATA) existence and die early.

Thanks!
Comment 3 Pavel Raiskup 2013-06-10 04:22:22 EDT
IMO, this really does not make much sense to fix.  We could hack around to
infinity trying to catch users mistakes this or similar way.  But why not to
push to rawhide cleanup fix, as I see the two things are not necessary in the
script: (a) check for symlink non-existence and (b) the -p parameter for mkdir
(as the script unconditionally fails when /var/lib/pgsql does not exist).

I think only Rawhide is usable target for this.  Tom, I can close this if it
does not make sense to you even that way.

diff --git a/postgresql-setup b/postgresql-setup
index e566106..a755e11 100644
--- a/postgresql-setup
+++ b/postgresql-setup
@@ -66,9 +66,9 @@ script_result=0
 
 # code shared between initdb and upgrade actions
 perform_initdb(){
-       if [ ! -e "$PGDATA" -a ! -h "$PGDATA" ]
+       if [ ! -e "$PGDATA" ]
        then
-               mkdir -p "$PGDATA" || return 1
+               mkdir "$PGDATA" || return 1
                chown postgres:postgres "$PGDATA"
                chmod go-rwx "$PGDATA"
        fi
Comment 4 Tom Lane 2013-06-10 09:52:28 EDT
I agree the -p option is kind of pointless in light of this discussion.

I'm less sure about removing the -h test ... what exactly does -e do if the target is a dangling symlink?  Or mkdir for that matter?  I think the idea there was that if you want to put the data directory on some other partition, it should be sufficient to make a symlink leading to the desired place at /var/lib/pgsql/data and then do initdb.  Obviously the code will work if you also make a directory at the pointed-to spot, but what if you try to leave that step to the script?

OTOH, this may largely be moot now that the script doesn't run as root.  It's not clear that there are useful setups in which the parent directory of a relocated data directory would be owned by postgres; and if it isn't, you'd have to make the data directory by hand, as root, anyway.
Comment 5 Pavel Raiskup 2013-06-10 10:47:18 EDT
(In reply to Tom Lane from comment #4)
> I agree the -p option is kind of pointless in light of this discussion.

Thanks, I'll commit that change.

> I'm less sure about removing the -h test ... what exactly does -e do if the
> target is a dangling symlink?  Or mkdir for that matter?
>
> I think the idea there was that if you want to put the data directory on some
> other partition, it should be sufficient to make a symlink leading to the
> desired place at /var/lib/pgsql/data and then do initdb.  Obviously the code
> will work if you also make a directory at the pointed-to spot, but what if
> you try to leave that step to the script?

For that functionality, we would have to incorporate readlink and try to create
the targed of the symlink, probably.

> OTOH, this may largely be moot now that the script doesn't run as root.
> It's not clear that there are useful setups in which the parent directory of
> a relocated data directory would be owned by postgres; and if it isn't, you'd
> have to make the data directory by hand, as root, anyway.

I thought about dangling symlink case.  But as it was not handled in
postgresql-setup (checked by quick testing), /usr/bin/initdb failed to win.

This check removal would make very unlikely fail to come little bit earlier in
code path - and I think that as users are familiar with initdb requirements,
they will not rely on automatic directory creation on a pointed-to place.

Thus I'll probably go for -h check removal — if nobody beats me :) — also.
Comment 6 Fedora Update System 2013-08-15 02:31:36 EDT
postgresql-9.2.4-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/postgresql-9.2.4-2.fc18
Comment 7 Fedora Update System 2013-08-15 02:37:30 EDT
postgresql-9.2.4-7.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/postgresql-9.2.4-7.fc19
Comment 8 Fedora Update System 2013-08-15 19:27:23 EDT
Package postgresql-9.2.4-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing postgresql-9.2.4-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-14828/postgresql-9.2.4-2.fc18
then log in and leave karma (feedback).
Comment 9 Fedora Update System 2013-08-17 20:38:11 EDT
postgresql-9.2.4-7.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 10 Fedora Update System 2013-10-17 10:21:23 EDT
postgresql-9.2.5-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/postgresql-9.2.5-1.fc18
Comment 11 Fedora Update System 2013-10-18 15:49:01 EDT
Package postgresql-9.2.5-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing postgresql-9.2.5-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-19316/postgresql-9.2.5-1.fc18
then log in and leave karma (feedback).
Comment 12 Fedora Update System 2013-10-28 23:40:48 EDT
postgresql-9.2.5-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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