Re: superuser() shortcuts

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.

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.

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.

B.i. Superuser can bypass that restriction.

B.ii. Superusers cannot bypass that restriction.

Which one shall it be?