From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | David Kohn <djk447(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: POC for a function trust mechanism |
Date: | 2018-08-10 00:58:59 |
Message-ID: | 20180810005859.GA32075@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 9, 2018 at 06:18:16PM -0400, David Kohn wrote:
> We certainly don't want to double-down on extending trust by allowing
> someone to modify someone else's trusted role list. Practically, if you
> are opening up permissions to someone, you will need to create a group
> that you both belong to first, and have them trust the group, or they
> can trust you directly. The benefit of a group role is that other
> people can be added to that group without having to modify the trusted
> role list. Basically, the function caller is trusting whoever controls
> membership to that group role. This is different from having someone
> trusting a role just because they were added to it (perhaps without
> their knowledge).
>
>
> I think if you trust a group role you are implicitly trusting any members of
> that group, because one can always alter the function owner from themselves to
> the group role, because they are a member of that group. So what you'd need to
> do is create a special group role that only owned the functions and then not
> make anyone an actual member of that group, but you could trust that group
> role. Then a separate group role that everyone would be a member of and you'd
Good point. I think you are right that if you trust a role, you trust
whoever controls role membership to add only trust-worthy people --- that
seems obvious because any member can create functions you will trust,
even if they don't change the function owner.
> do grants from the first role to the second.
> So for what you proposed, if you are opening up permissions to someone by using
> a role that you are both members of, then you implicitly open up permissions
> from them to you as well.
I don't see the value in that. My point is that you can't trust anyone
in a role you are a member of, by default --- you have to make that
decision as a user.
> Anyway, I guess all of this seems to introduce a lot more complexity into an
> already complex permissions management system...is this all about the public
> schema? Can we just make create function/operator etc something you have to
> grant even in the public schema? It seems like that could be significantly more
> user friendly than this. Or otherwise, would functions owned by the database or
I think 95% of users are proabably creating these things as the
accessing user or super-user.
> schema owner be exempt from this? Because there are many setups where people
> try to avoid superuser usage by creating database or schema owner users who can
> do things like create function, which a normal users can now use. Would checks
> be skipped if the function call is schema qualified because then there's no
> reasonable way to think that someone is being fooled about which function they
> are executing?
I think most setups will be pretty simple.
--
Bruce Momjian <bruce(at)momjian(dot)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 +
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2018-08-10 01:07:42 | A dubious message related to SP-GiST compress method. |
Previous Message | Tom Lane | 2018-08-09 23:56:37 | Re: CF 2018-07 Needs Review items |