Re: createdb but revoke dropdb

From: Ben Eliott <ben(dot)apperrors(at)googlemail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: createdb but revoke dropdb
Date: 2010-03-03 09:57:37
Message-ID: D8C58AE6-A89A-416F-B049-C8E67B576840@googlemail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

Thank-you for coming back and your advice. I understand what you mean.
However, in order to run the script without additional user
input, .pgpass is always needed. One way or another, which ever way i
try and twist this, something has to give on security. Perhaps it
would be just about ok-ish if I could restrict the linux user to just
creating databases, but the privilege to add a database means the
privilege to drop them too. And ok-ish isn't great either.

So, rather than fight this I think perhaps instead another approach -
to pre-prepare sets of databases ahead of time and then, rather than
create them programmatically, just assign them programmatically
instead. It doesn't exactly solve the original problem, but I think i
prefer it from a security standpoint anyhow.

Ben

On 3 Mar 2010, at 09:17, Richard Huxton wrote:

> On 02/03/10 18:22, Ben Eliott wrote:
>> I have two roles, 'adminuser' with createdb permission, and
>> 'dbuser' a
>> user with CRUD privileges.
>>
>> adminuser is a member of the dbuser role, this seems to allow
>> adminuser
>> to createdb databases for dbuser with:
>> createdb -U adminuser -O dbuser new_database_name
>> Adding .pgpass to the linux user's home directory allows createdb to
>> work without additional user input.
>>
>> But now it seems the linux user also has dropdb privileges. How can i
>> restrict this?
>> Perhaps there is a recommended method to disable dropdb? Can anyone
>> suggest?
>
> From the SQL reference page for "GRANT"
> "The right to drop an object, or to alter its definition in any way,
> is not treated as a grantable privilege; it is inherent in the
> owner, and cannot be granted or revoked. (However, a similar effect
> can be obtained by granting or revoking membership in the role that
> owns the object; see below.) The owner implicitly has all grant
> options for the object, too."
>
> Don't make "dbuser" the owner of the database, make "adminuser" the
> owner, then grant whatever top-level privileges dbuser needs. Make
> sure you don't have adminuser as an automatic login through .pgpass
>
>> The adminuser has no login privileges so by removing dropdb this
>> should
>> remove the possibility for any hacker chaos other than creating more
>> databases?
>
> Or deleting/modifying all your data, presumably. If you don't trust
> the linux user account, don't give it automatic login.
>
> --
> Richard Huxton
> Archonet Ltd

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Robst 2010-03-03 10:38:17 LDAP Login Problem
Previous Message Richard Huxton 2010-03-03 09:41:18 Re: FSM and VM file