Re: Worst case scenario of a compromised non super-user PostgreSQL user account

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Allan Kamau <kamauallan(at)gmail(dot)com>
Cc: Postgres General Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Worst case scenario of a compromised non super-user PostgreSQL user account
Date: 2011-02-21 08:37:15
Message-ID: 4D62243B.2060108@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 21/02/2011 3:44 PM, Allan Kamau wrote:

> Are there other problems we may expect. Can they run any OS programs
> or install any such tools, induce buffer overflows and so on.?

So long as your webapp user and database owner is a regular user
(non-superuser) without CREATE ROLE or CREATE DATABASE rights, they
should be pretty well sandboxed, though as you point out they can
attempt to affect the rest of the system by running expensive queries.

If your webapp user is a superuser and the webapp gets cracked, you're
screwed. Don't do it. Ever.

To be even safer, you should consider not even making your webapp user
the database owner. Have a different user create the database, own it,
and run the DDL to create and maintain its tables. Explicitly GRANT the
webapp user the rights it requires on the tables, views and functions it
uses, and no more. This may not be practical if your webapp likes to run
its own generated DDL during upgrades (like Rails, Drupal, etc) or lacks
any sort of documentation on what access rights it needs.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Craig Ringer 2011-02-21 08:42:47 Re: 回复: [GENERAL] How to make the user-defined function or type beingaccessed in the global database server?
Previous Message Yan Cheng CHEOK 2011-02-21 08:19:32 Re: Duplicated tables of certain columns