Thread: Problem Accessing PostgreSQL from Perl CGI
Hello all,
I'm trying to access my Postgres data base in perl Using DBI->connect
--------------------------------------------------------------------------------------------------------------------------------------------------
A few important things to note:
1) I've checked the permissions on both the /tmp directory and the socket file, and both are 777 (wide open)
2) I am able to access the database from php using pg_connect
3) I can access Postgres with DBI->connect when I run the perl script from the command line, it's when
I try to access Postgres from the perl CGI in a web application that I get this message
4) I have the following in my pg_hba.conf file:
---------------------------------------------------------------------------
local all all md5
host all all 0.0.0.0 0.0.0.0 md5
--------------------------------------------------------------------------
I think this should allow anyone to access any database from any ip address using md5 -- correct me if I'm wrong.
5) I added apache to the appropriate group to make sure apache has permission to the proper files
I have changed every permission I can think of, short of chmod 777 -R /
I'm about out of ideas.
I don't think it is a version incompatibility since everything works fine from the command line, but just in case here are the versions
Postgres: 4.7.4
Perl 5.8.5
Thank you for your consideration,
RYan Miller
I'm trying to access my Postgres data base in perl Using DBI->connect
--------------------------------------------------------------------------------------------------------------------------------------------------
DBI connect('dbname=visualizer','visualizer',...) failed: could not connect to server: Permission denied
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
--------------------------------------------------------------------------------------------------------------------------------------------------
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
--------------------------------------------------------------------------------------------------------------------------------------------------
A few important things to note:
1) I've checked the permissions on both the /tmp directory and the socket file, and both are 777 (wide open)
2) I am able to access the database from php using pg_connect
3) I can access Postgres with DBI->connect when I run the perl script from the command line, it's when
I try to access Postgres from the perl CGI in a web application that I get this message
4) I have the following in my pg_hba.conf file:
---------------------------------------------------------------------------
local all all md5
host all all 0.0.0.0 0.0.0.0 md5
--------------------------------------------------------------------------
I think this should allow anyone to access any database from any ip address using md5 -- correct me if I'm wrong.
5) I added apache to the appropriate group to make sure apache has permission to the proper files
I have changed every permission I can think of, short of chmod 777 -R /
I'm about out of ideas.
I don't think it is a version incompatibility since everything works fine from the command line, but just in case here are the versions
Postgres: 4.7.4
Perl 5.8.5
Thank you for your consideration,
RYan Miller
ryan miller <ryemiller@gmail.com> writes: > DBI connect('dbname=3Dvisualizer','visualizer',...) failed: could not conn= > ect > to server: Permission denied That certainly looks like a file permissions problem --- it's *not* the PG server refusing you access, it's the kernel. > 1) I've checked the permissions on both the /tmp directory and the socket > file, and both are 777 (wide open) > 2) I am able to access the database from php using pg_connect > 3) I can access Postgres with DBI->connect when I run the perl script from > the command line, it's when > I try to access Postgres from the perl CGI in a web application that I get > this message Hm. Are you perhaps running this in a recent Red Hat or Fedora release; if so do you have SELinux enforcement enabled; and if so, does the error go away when you disable enforcement? If so it means the security policy is the problem. The policy normally tries to be restrictive about what daemon processes can do, but it's evidently being a bit too restrictive here. Update to latest policy, and if it still fails, file a bug against the selinux-policy component. regards, tom lane