Secure Postgres access

[Paul Rubin]

Reid Priedhorsky <reid at umn.edu> writes:
> > Wouldn't they need a database password?
> 
> Well, right now, no. I have Postgres configured to trust the OS on who is
> who. 

You trust the OS on the client machine, but not the client machine's
users?  Does it run identd?  Maybe you could use that.  I'd consider
this shaky for any real security application, but it might be better
than nothing depending on what you're doing.

> I would prefer not to change that because I don't want another place
> containing authentication information. I'd like to connect by entering
> only my SSH password, not my SSH password and a database password too.

How about if you hack your local SSH client so its port forwarding
only accepts connections originated by your account, again using
identd to check.  Your application could also open a second connection
to the hacked client, using an AF_UNIX socket, which in linux supports
a sendmsg command that sends the other side's user id (see the
SCM_CREDENTIALS message in unix(7)).  You'd use SCM_CREDENTIALS to
authenticate the user ID, then send the Postgres client's originating
TCP port number over the Unix socket, and that would tell the SSH
client that it could then start forwarding the TCP packets.  Yucch,
this is messy.  Maybe something like it exists already somewhere.

> I control the database machine, and the only user is me. I don't control
> the local machine, and it has many users I don't trust.

Sooner or later they will take over your account and capture your ssh
and login passwords, and then there will be no way at all for any
program to distinguish between them and you.  Your best bet is to run
on a client machine that you trust.