Nelson Ferreira Junior <nelson@mercurio.econnect.com.br> writes:
> The only thing it does is to catch the SQL command that is supplyed in
> a HTML form and pass this command to PostgreSQL's backend, showing the
> results of the query in a html table.
> It works well with SELECT stataments, but it can't execute INSERT ou
> DELETE commands. The user nobody (wich Apache is running over) has all
> permissions set (I used : "grant all mytable to nobody;"). I can do these
> INSERTs and DELETEs normaly with psql inteface, under user nobody ???
Some possibilities:
1. Are you sure this is a permissions problem? INSERT and DELETE don't
return a table, only a status indication, so I could imagine that your
code is falling over on the no-table case.
2. It could be that the CGI code is not actually running as "nobody" as
you think, but as some other user. Are you specifying the Postgres
username explicitly by using PQsetdbLogin (or setting PGUSER environment
variable)? If you're just allowing it to default, it might not be
defaulting to what you think. The default table permissions in Postgres
(with no GRANT) are *no* access, not read-only access, so the CGI code
must be logged in as some user granted read access by the table
permissions.
3. There was a thread here a few days ago about someone else's problems
getting a CGI script to run (thread 'getting "fe_setauthsvc: invalid
name" error'), and the upshot was this:
: I used some C code from the examples directory to make the same
: connection through the web server. I still wasn't getting connected,
: but at least the error message in the server's log was informative: it
: said it failed during a call to getprotobyname(). I had no clue what it
: was, but looked it up. It says that it reads /etc/protocols. I somehow
: "knew" that /etc/protocols didn't exist while running through the web
: server; our hosting company had mentioned before that the file
: permissions, etc. are different - more protected - from httpd. So, the
: easy fix was to copy /etc/protocols to ~/etc/protocols (a directory
: "readable" from our virtual server's httpd process. It worked like a
: charm. :)
This was a connect-time failure, so it's not directly relevant to your
problem, but it does illustrate that the environment of a CGI script can
be a lot different from the usual. You should try the script standalone
(run it as yourself, feed it some data and see what comes out). Once
that works, you can worry about whether it has environment dependencies
that might fail when it runs as a CGI script.
regards, tom lane
