Обсуждение: Re: [INTERFACES] getting "fe_setauthsvc: invalid name" error
Tom Lane wrote:
>
> My guess is that the execution environment is different for your CGI
> program, with respect to either username or lack of one of the
> environment variables that libpq pays attention to (PGPORT, etc).
I think you're right, Tom. If I run the program on my Linux box as a
different user, I get the same error. Now, how do I set the username
from C/C++?? I can't figure it out from the docs ...
> BTW, hackers: when I looked into pgconnection.cc, I was astonished
> and dismayed by the number of instantly visible bugs. This code is in
> *horrible* shape --- it's amazing it works at all. Someone is going to
> have to adopt libpq++ and give it a close going-over.
I wish I knew enough about C++. :)
Thanks for your help, Tom!
Clint
----------------------------------------------------------------------------
Belinda & Clint Forgy
Midwest Online PeculiarWeb Internet Designs
http://www.midwestonline.com http://www.peculiarweb.com
Clint wrote: > >I think you're right, Tom. If I run the program on my Linux box as a >different user, I get the same error. Now, how do I set the username >from C/C++?? I can't figure it out from the docs ... > At the first glance I would suggest you either do a chown(1) on the program binary so that is executes as the correct user or you have a set*id(2) call somewhere in the program source. However, you should take care with that as this can result in a security leak in your system. Torsten -- InWise - Wirtschaftlich-Wissenschaftlicher Internet Service GmbH Friedrichshulder Weg 56 Tel: +49-4101-403605 D-25469 Halstenbek Fax: +49-4101-403606 E-Mail: info@inwise.de WWW: http://www.inwise.de
On Wed, 16 Sep 1998, Torsten Neuer wrote: > Clint wrote: > > > >I think you're right, Tom. If I run the program on my Linux box as a > >different user, I get the same error. Now, how do I set the username > >from C/C++?? I can't figure it out from the docs ... > > At the first glance I would suggest you either do a chown(1) on > the program binary so that is executes as the correct user or you > have a set*id(2) call somewhere in the program source. > However, you should take care with that as this can result in a > security leak in your system. Its in http://www.PostgreSQL.ORG/docs/postgres/libpq9374.htm Read the section on "PQsetdbLogin - Makes a new connection to a backend" PGconn *PQsetdbLogin(const char *pghost, const char *pgport, const char *pgoptions, const char *pgtty, const char *dbName, const char *login, const char *pwd); If any argument is NULL, then the corresponding environment variable is checked. If the environment variable is also not set, then hardwired defaults are used. PQsetdbLogin always returns a valid PGconn pointer. The PQstatus (see below) command should be called to ensure that a connection was properly made before queries are sent via the connection. It's so easy... If you should want to set environment variables anyway: environ(5), getenv(3) and putenv(3) tell you how. Finally: Don't deal with set*id() calls unless absolutely neccessary AND you really know what you do.The first condition returns FALSE here. sebastian -- __o Sebastian Meyer Tel: (0421)218-7702 | "Everything should be _ \<,_ meyer@mevis.de http://www.mevis.de | made as simple as possible, (_)/ (_) MeVis an der Universität Bremen | but not simpler." ~~~~~~~~~~~ Universitätsallee 29, D-28359 Bremen | - Albert Einstein
Sebastian Meyer <meyer@mevis.de> writes: > On Wed, 16 Sep 1998, Torsten Neuer wrote: >> Clint wrote: >>>> I think you're right, Tom. If I run the program on my Linux box as a >>>> different user, I get the same error. Now, how do I set the username >>>> from C/C++?? I can't figure it out from the docs ... > Its in http://www.PostgreSQL.ORG/docs/postgres/libpq9374.htm > Read the section on "PQsetdbLogin - Makes a new connection to a backend" Ah, but Clint's real problem is that he's not calling libpq directly, but via libpq++. And as far as I can see, libpq++ doesn't have any way to open a connection except by calling plain old PQsetdb. This needs to be fixed. (We should add an entry point to libpq++ that corresponds to PQconnectdb, so that the connection parameters are passed through as a single string and libpq++ doesn't have to know about each and every one of 'em.) The short-term workaround is what you mention next: > It's so easy... If you should want to set environment variables anyway: > environ(5), getenv(3) and putenv(3) tell you how. Setting PGUSER (and PGPASSWORD if needed) env. variables will provide a way to pass these items to libpq despite the lack of any cooperation from libpq++. regards, tom lane
Tom Lane wrote:
>
> Ah, but Clint's real problem is that he's not calling libpq directly,
> but via libpq++. And as far as I can see, libpq++ doesn't have any way
> to open a connection except by calling plain old PQsetdb. This needs to
> be fixed. (We should add an entry point to libpq++ that corresponds to
> PQconnectdb, so that the connection parameters are passed through as a
> single string and libpq++ doesn't have to know about each and every one
> of 'em.)
>
> The short-term workaround is what you mention next:
>
> > It's so easy... If you should want to set environment variables anyway:
> > environ(5), getenv(3) and putenv(3) tell you how.
>
> Setting PGUSER (and PGPASSWORD if needed) env. variables will provide a
> way to pass these items to libpq despite the lack of any cooperation
> from libpq++.
Bingo! Tom, what you said about PGUSER triggered something I was
wondering about: if running as a virtual web server was different (and
how) from running at the command line. Here's the fix I used:
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. :)
I have no clue if it's a "legitimate" fix, or if any harm can be done,
but for now it's staying. :)
Thanks go out to Tom Lane and everybody that offered help!
Clint
----------------------------------------------------------------------------
Belinda & Clint Forgy
Midwest Online PeculiarWeb Internet Designs
http://www.midwestonline.com http://www.peculiarweb.com