Re: Disable executing external commands from psql?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Disable executing external commands from psql?
Date: 2010-06-02 00:30:21
Message-ID: 12036.1275438621@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com> writes:
>> The better way to go about that is to not let them have an account on
>> the server machine in the first place.

> Somehow, exposing my database ports to the internet scares me more than
> any (possibly crazy) stuff I'm trying to do. :)

If you're exposing the ability to run psql, what makes you think you're
not effectively exposing the database?

> But seriously I think I need to give them accounts--I'm setting up
> online instances of a web app, so they have a set of (editable) PHP
> files, possibly some storage, a log file, etc. It seemed that setting
> each up as its own user was better than going through some uber-process
> that had access to all the files.

How are you going to let them edit the PHP files, or read the log file,
if all they can get to is psql?

> Just to be clear, cause I'm a little thick sometimes, it is not possible
> to do this?

You could always build your own lobotomized version of psql. I think
though that (a) this is not likely to close all the holes and (b) the
whole concept needs rethinking anyway. psql is *meant* to be executed
on the client side. You're trying to put the firewall in the wrong
place, and what you're mainly going to accomplish is annoy your users.
You will for example be making it awfully difficult for them to use
\copy, \i, \e, \g, the list goes on.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2010-06-02 00:32:28 Re: PosttgreSQL on AIX
Previous Message Ernesto Quiñones 2010-06-02 00:28:54 Re: PosttgreSQL on AIX