Re: superuser() shortcuts

* Peter Eisentraut (peter_e(at)gmx(dot)net) wrote:
> On 11/21/14 10:28 AM, Stephen Frost wrote:
> > Specifically:
> > ---------------
> > One curious item to note is that the
> > current if(!superuser()) {} block approach has masked an inconsistency
> > in at least the FDW code which required a change to the regression
> > tests- namely, we normally force FDW owners to have USAGE rights on
> > the FDW, but that was being bypassed when a superuser makes the call.
> > I seriously doubt that was intentional. I won't push back if someone
> > really wants it to stay that way though.
> > ---------------
>
> I think there are some inconsistencies here.

Agreed.. We certainly have a number of inconsistencies and I'd love to
reduce them. :)

> To rephrase the problem:
>
> 1. To run CREATE SERVER, you need USAGE rights on FDW.
>
> 2. To run ALTER SERVER OWNER as unprivileged user, the new owner also
> needs USAGE rights on FDW.
>
> 3. When you run ALTER SERVER OWNER as superuser, the new owner does not
> need USAGE rights on FDW.
>
> -> The proposal is to change #3 to require the new owner to have USAGE
> privileges even when running as superuser.

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.

> Let's look at an analogous case:
>
> 1. To run CREATE DOMAIN, you need USAGE rights on the underlying type.
>
> 2. To run ALTER DOMAIN OWNER, the receiving user does not need USAGE
> rights on the underlying type.
>
> These two cases are inconsistent.
>
> There might be more analogous cases involving other object classes.
>
> Solution, either:
>
> A. We allow unprivileged users to "give away" objects to other
> unprivileged users who do not have the privileges that they could have
> created the object themselves. This could be a marginally useful
> feature. But it might also violate the privilege system, because it
> effectively allows you to bypass the grant options.
>
> or
>
> B. For unprivileged users to "give away" an object to another
> unprivileged user, the receiving user must have the privileges so that
> they could have created the object themselves.

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.

> B.i. Superuser can bypass that restriction.
>
> B.ii. Superusers cannot bypass that restriction.

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.

Thanks!

Stephen