After installing dev-db/postgresql-server-8.4.3, I initialized the database (having to work around bug 319685). After initializing the database, setting up users and passwords, and then PROPERLY configuring the authorization file pg_hba.conf, the postgresql init would no longer properly start. Although the database server does start, the init script waits a very long time before reporting that it was unable to start the server because it couldn't find the PID file. Upon looking at the /var/lib/postgresql/8.4/data/postmaster.log file, I noticed the following error, repeated multiple times: FATAL: no pg_hba.conf entry for host "[local]", user "postgres", database "postgres", SSL off So the init script was trying to connect to the server that it just started by using the postgres user and since there was no pg_hba.conf rule allowing the postgres user to connect, it was failing. This is a MAJOR security issue. It would seem that the script requires the administrator to allow local connections with "trust" authentication. This is completely unacceptable, as it would allow any user with a shell to impersonate any postgresql user that they liked. Using a .pgpass file for root and/or the postgres user does not seem to work. As it stands I can find no work-around for this issue, besides allowing all local users to connect with "trust" auth. I don't know why the maintainers decided to break the init script in this way, but it makes absolutely no sense. The ability to connect to a server is only tangentially related to whether or not the server started properly. Please fix this as soon as possible. Reproducible: Always Steps to Reproduce: 1. emerge =dev-db/postgresql-server-8.4.3 2. emerge --config =dev-db/postgresql-server-8.4.3 3. Remove the "local all all trust" line from pg_hba.conf 4. /etc/init.d/postgresql-8.4 start 5. Observe "could not start server" after 90 seconds Actual Results: The server "fails" to start with "could not start server" after 90 seconds when local trust authentication is not enabled. Although the postgresql process is started and accepts connects, the init script's state is totally wrong. Expected Results: The server should start and the script should properly report it as started, EVEN IF A CONNECTION TO THE SERVER CAN NOT BE MADE.
Please try the init script from bug #311047.
(In reply to comment #1) > Please try the init script from bug #311047. > I had to remove the extra parenthesis from line 60 to get the script to "work". Once I did, I was greeted with the same messages I was seeing before (in the postmaster.log file), but in my terminal this time. I would say that script is an improvement over the old one, but it doesn't fix the problem I reported.
(In reply to comment #2) > (In reply to comment #1) > > Please try the init script from bug #311047. > > > > I had to remove the extra parenthesis from line 60 to get the script to "work". > Once I did, I was greeted with the same messages I was seeing before (in the > postmaster.log file), but in my terminal this time. > > I would say that script is an improvement over the old one, but it doesn't fix > the problem I reported. > Did you also give the conf a shot and pass PGPASS as an extra environment variable?
Well, I've reproduced the error with a "blank" pg_hba.conf. The server starts, but it doesn't look that way to the scripts. However, when the line looks like so: local all all password The server starts and can be properly handled by the init script. That's without any extra environment settings. (I didn't have to pass PGPASSFILE to pg_ctl.) The issue lies in pg_ctl being unable to connect to the server in any manner other than through a socket. (Indeed, allowing remote pg_ctl would actually be a larger security issue than trusting local users, and trusting local users is not a requirement of the script to work.) As such, there doesn't seem to be anything for us to do to fix this.
P.S.: Because the server does actually start, you need to kill it manually before the init script will be able to handle it.
P.P.S.: You need more than a shell to access the PgSQL server as any user. The user also needs to be in the 'postgres' system group. root would be the exception to this, obviously, but if your root account is cracked, you have larger issues to be concerned about.
(In reply to comment #6) > P.P.S.: You need more than a shell to access the PgSQL server as any user. The > user also needs to be in the 'postgres' system group. root would be the > exception to this, obviously, but if your root account is cracked, you have > larger issues to be concerned about. > Okay, but if apache is able to make connections (which is required for web applications) then any user with FTP access can upload a PHP script that connects as the postgres user with full access to the database.
(In reply to comment #7) > (In reply to comment #6) > > P.P.S.: You need more than a shell to access the PgSQL server as any user. The > > user also needs to be in the 'postgres' system group. root would be the > > exception to this, obviously, but if your root account is cracked, you have > > larger issues to be concerned about. > > > > Okay, but if apache is able to make connections (which is required for web > applications) then any user with FTP access can upload a PHP script that > connects as the postgres user with full access to the database. > Well ... I just did some tests and maybe you are right. I can't connect without a password from the apache user, but connecting with a password works fine. I guess with the new conf and init scripts, the issue is more obvious (and doesn't require looking through log files to determined what happened). If you are a maintainer, feel free to close the bug as you see fit.
The new inits have been committed to the tree along with the -r1 ebuilds. This bug should be resolved.
