Re: Disabling START TRANSACTION for a SuperUser - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Disabling START TRANSACTION for a SuperUser
Date
Msg-id 1857745666.242023.1445954826713.JavaMail.yahoo@mail.yahoo.com
Whole thread Raw
In response to Re: Disabling START TRANSACTION for a SuperUser  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: Disabling START TRANSACTION for a SuperUser  (Muthiah Rajan <vgmonnet@gmail.com>)
Re: Disabling START TRANSACTION for a SuperUser  (Bernd Helmle <mailings@oopsware.de>)
List pgsql-hackers
On Tuesday, October 27, 2015 8:52 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 27 October 2015 at 21:19, rajan <vgmonnet@gmail.com> wrote:

>> Thanks for your response. Seems like the workaround is difficult.
>>
>> I am trying to understand
>> "
>> ExecutorStart_hook and ProcessUtility_hook

> Doing what you want will require being willing to spend a fair bit of
> time becoming familiar with PostgreSQL's innards, writing extensions,
> etc. It's not a simple "download, compile, run" process. You will need
> to be confident with C programming and reading source code.

> If this is going way too deep, perhaps you should post to
> pgsql-general with a description of the underlying problem you are
> trying to solve, i.e. *why* you want to be able to have a superuser
> who can alter users but can't select, etc. What's the problem you're
> trying to solve with this?

This is a question I have seen before, as well as slight variations
on it related to transaction isolation level.  Right now you can
implement a read-only user by granting only SELECT rights to tables
and also by setting the default_transaction_read_only = on.  The
problem is that the latter is essentially just a suggestion, not an
order.  I actually don't think it's as big a problem with read-only
users, since that can still be accomplished (with enough work) by
using the GRANT/REVOKE commands.  (Think how much faster and easier
it could be if there is a role that allows the appropriate set of
SELECTs but also allows some DML -- just set a read-only rule for
the user and the existing role could work.)

It is more problematic where a shop wants to use serializable
transactions to ensure data integrity.  The only way to prevent
someone from subverting the business rules is to code a lot of
triggers on a lot of objects that throw an error if the isolation
level is wrong.  It would be a boon to big shops if they could
declare (preferably with the option to set it at a role level) that
specific default_transaction_* settings could not be overridden.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: remaining open items
Next
From: Alvaro Herrera
Date:
Subject: Re: remaining open items