Reid Priedhorsky <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
