Re: superuser() shortcuts

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: superuser() shortcuts
Date: 2014-12-06 14:23:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 12/4/14 3:32 PM, Stephen Frost wrote:
> On reflection, this seemed odd because of how the code was written but
> perhaps it was intentional after all. In general, superuser should be
> able to bypass permissions restrictions and I don't see why this case
> should be different.

> In general, I don't think we want to allow "giving away" of objects by
> unprivileged users. We don't allow that to be done for tables and I'm
> surprised to hear that it's possible to give domains away.

> Superuser should be able to bypass the restriction, BUT the object given
> away by the superuser to an unprivileged user should NOT be able to be
> further given away by that unprivileged user.

Clearly, this issue is a bit more complex than a simple code cleanup.
So I'm going to set this patch as returned with feedback.

My suggestion for moving forward would be to define a general security
policy for the ALTER OWNER cases, and then fix those properly.

The changes for integration the superuser check into the replication
role check should perhaps be tackled as part of a general refactoring of
capability checks.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-12-06 15:11:33 Re: Role Attribute Bitmask Catalog Representation
Previous Message Michael Paquier 2014-12-06 14:07:38 Re: [REVIEW] Re: Compression of full-page-writes