Re: POC for a function trust mechanism - Mailing list pgsql-hackers

On Thu, Aug  9, 2018 at 02:12:41PM -0400, David Kohn wrote:
> On Thu, Aug 9, 2018 at 12:11 PM Bruce Momjian <bruce@momjian.us> wrote:
>     I can't think of any other places we do transitive permissions, except
>     for role membership.  I don't see the logic in adding such transitivity
>     to function/operator calls, or even a per-function GUC.  I assume most
>     sites have a small number of extensions installed by a predefined group
>     of users, usually superusers. If there is a larger group, a group role
>     should be created and those people put in the role, and the group role
>     trusted.
> 
> 
> I am wondering how this will interact with the inheritance of roles. For
> instance, if two users are members of the same role, and one creates a function
> the expectation would be that other users in the same role will not trust that
> function.

Well, right now, if you want to give members of a role rights to
something, you have to specifically grant rights to that role.  I would
assume the same thing would happen here --- if you want to trust a group
role, you have to mention that group role in the GUC list (not
function-level GUC).

Do we allow any GUC on a function?  Would not allowing this be confusing?

If we did transitive permissions, I could trust someone, and that person
could call a function of someone else they trust, and after a while you
don't know who you are trusting, which is why I think complex setups
like that are unwise.

> However, do I trust functions that are owned by the roles that I am a
> member of? Or do I have to list any nested roles explicitly? If the former, I
> suppose we'd have to modify how alter function set owner works. It is currently
> allowed for roles that you are a member of (and would then create a security
> hole). However, not trusting functions owned by roles that I am a member of
> seems to also be a bit counterintuitive.

Well, if someone adds me to the 'bad' role, do I have any control over
that?  Seems someone adding me to their role is not something I am
requesting.  Let's look at the docs on GRANT ROLE:

   GRANT on Roles
       This variant of the GRANT command grants membership in a role to
       one or more other roles. Membership in a role is significant because
       it conveys the privileges granted to a role to each of its members.

       If WITH ADMIN OPTION is specified, the member can in turn grant
       membership in the role to others, and revoke membership in the role
       as well. Without the admin option, ordinary users cannot do that. A
       role is not considered to hold WITH ADMIN OPTION on itself, but it
       may grant or revoke membership in itself from a database session
       where the session user matches the role. Database superusers can
       grant or revoke membership in any role to anyone. Roles having
       CREATEROLE privilege can grant or revoke membership in any role
       that is not a superuser.

       Unlike the case with privileges, membership in a role cannot be
       granted to PUBLIC. Note also that this form of the command does
       not allow the noise word GROUP.

The point is that it is granting the role _access_ to something, not
something trust that the role accepts.  The WITH ADMIN OPTION would
allow ordinary users to add roles for whoever they want to attack.

Basically, as it is now, someone adding me to their role membership has
no downside for me.  To trust my own role membership adds a downside to
role membership that I don't think we want to do --- it makes role
membership too complex in what it grants _and_ trusts.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +