Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA05516; Thu, 30 Apr 92 12:20:51 -0700
Message-Id: <9204301920.AA05516@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: Who am I?
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Wed, 29 Apr 92 12:04:35 +0700."
             <9204291006.AA16801@postgres.Berkeley.EDU> 
Date: Thu, 30 Apr 92 12:20:39 PDT

you write:

> I had to look in $POSTGRESHOME/src/lib/libpq/*.c, because I wanted to
> execute queries from a host during system boot. I always got a core
> dump and so I found in fe-pqexec.c:

 ...
>         if (pq_connect(PQdatabase, getenv("USER"), PQoption, PQhost, PQtty,
>                         (char *) NULL, (short)atoi(PQport) ) == -1 ) {
>             libpq_raise(&ProtocolError,
>               form((int)"Failed to connect to backend (host=%s, port=%s)",
>                    PQhost, PQport));
>         }
> 
> EstablishComm() initializes a connection. This functions gets the user name 
> using the getenv() function. I got core dumps, because there is no environment
> variable USER during system boot. Now, I looked into pq_connect() and I
> found that the user name is transmitted to the backend as a normal string.

bug above.

> It should be clear, that fooling a backend about the user identity 
> is no problem. We are currently thinking about using kerberos to
> authenticate user for remote database access.

This is one of the many reasons why I often tell everyone that security
in postgres is nonexistant.


Jeff Meredith
mer@postgres.berkeley.edu