On Tue, 26 Jun 2007, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > All that really has to happen is that dblink should by default not be
> > callable by any user other than Postgres.
>
> Yeah, that is not an unreasonable change. Someone suggested it far
> upthread, but we seem to have gotten distracted :-(
An idea came to me while thinking about this. The particular use-case
that I use dblink for is connecting to another database in the same
database cluster. ISTM (without looking at any code) that the postmaster
could keep track of who is properly authenticated in each backend, and see
if a connection is being created from that backend to allow connections as
the user in that backend.
I had a couple ideas about this:
1. If you can tell what process is connecting on a local socket, store a
mapping of pid to userid in the postmaster shmem and if a connection is
originating from a pid in this table and is attempting to authenticate as
the corresponding userid, allow it.
2. If you cannot tell what process is connecting on a local socket (which
I suspect you cannot portably), generate a random "token" and stash it in
shared memory mapping it to a userid, and then on authentication, send
this token to the postmaster to prove that you have already authenticated.
This has the downside of turning an exploit where a non-privileged user
can read arbitrary postgres memory, they could potentially gain the
privilieges of any logged on user, but the best idea is to not have that
kind of bug ;)
I know this is not the time for thinking about such things, but it may be
an idea for 8.4...
--
It's really quite a simple choice: Life, Death, or Los Angeles.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
