Hi,
We've had some previous discussions about when to use
has_privs_of_role and when to use is_member_of_role, and
has_privs_of_role has mostly won the fight. That means that, if role
"robert" is set to NOINHERIT and you "GRANT stuff TO robert", for the
most part "robert" will not actually be able
Robert Haas:
Well, maybe. Suppose that role A has been granted pg_read_all_settings
WITH INHERIT TRUE, SET TRUE and role B has been granted
pg_read_all_settings WITH INHERIT TRUE, SET FALSE. A can create a
table owned by pg_read_all_settings. If A does that, then B can now
create a trigger on tha
On Sun, Sep 25, 2022 at 5:08 AM Wolfgang Walther
wrote:
> Robert Haas:
> > Well, maybe. Suppose that role A has been granted pg_read_all_settings
> > WITH INHERIT TRUE, SET TRUE and role B has been granted
> > pg_read_all_settings WITH INHERIT TRUE, SET FALSE. A can create a
> > table owned by pg_
Robert Haas:
This shows that if rhaas (or whoever) performs DML on a table owned by
pg_read_all_settings, he might trigger arbitrary code written by alice
to run under his own user ID. Now, that hazard would exist anyway for
tables owned by alice, but now it also exists for any tables owned by
pg
On Mon, Sep 26, 2022 at 12:16 PM Wolfgang Walther
wrote:
> I think, when WITH INHERIT TRUE, SET FALSE is set, we should:
> - Inherit all explicitly granted privileges
> - Not inherit any DDL privileges implicitly given through ownership:
> CREATE, REFERENCES, TRIGGER.
> - Inherit all other privile
Robert Haas:
I don't think we're going to be very happy if we redefine inheriting
the privileges of another role to mean inheriting only some of them.
That seems pretty counterintuitive to me. I also think that this
particular definition is pretty fuzzy.
Scratch my previous suggestion. A new, l
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Sep 8, 2022 at 1:06 PM wrote:
> > In theory, I could also inherit that privilege, but that's not how the
> > system works today. By using is_member_of_role, the decision was already
> > made that this should not depend on inheritan
Greetings,
* Wolfgang Walther (walt...@technowledgy.de) wrote:
> Robert Haas:
> > I don't think we're going to be very happy if we redefine inheriting
> > the privileges of another role to mean inheriting only some of them.
> > That seems pretty counterintuitive to me. I also think that this
> > p
On Mon, Sep 26, 2022 at 3:16 PM Wolfgang Walther
wrote:
> Robert Haas:
> > I don't think we're going to be very happy if we redefine inheriting
> > the privileges of another role to mean inheriting only some of them.
> > That seems pretty counterintuitive to me. I also think that this
> > particul
Robert Haas:
Scratch my previous suggestion. A new, less fuzyy definition would be:
Ownership is not a privilege itself and as such not inheritable.
[...]
If I'm understanding correctly, this would amount to a major
redefinition of what it means to inherit privileges, and I think the
chances of
On Tue, Sep 27, 2022 at 2:05 AM Wolfgang Walther
wrote:
> I'm just saying WITH SET FALSE should take away more of the things you
> can do (all the ownership things) to a point where it's safe to GRANT ..
> WITH INHERIT TRUE, SET FALSE and still be useful for pre-defined or
> privilege-container ro
On Mon, 2022-09-19 at 15:32 -0400, Robert Haas wrote:
> One could take the view that the issue here is that
> pg_read_all_settings shouldn't have the right to create objects in
> the
> first place, and that this INHERIT vs. SET ROLE distinction is just a
> distraction. However, that would require a
On Mon, 2022-09-26 at 15:40 -0400, Stephen Frost wrote:
> Predefined roles are special in that they should GRANT just the
> privileges that the role is described to GRANT and that users really
> shouldn't be able to SET ROLE to them nor should they be allowed to
> own
> objects, or at least that's
On 8/25/22 12:12, Robert Haas wrote:
So far, so good. But it's clearly not the case that "GRANT stuff TO
robert" has conferred no privileges at all on robert. At the very
least, it's enabled him to "SET ROLE stuff", but what else? I decided
to go through the code and make a list of the things tha
On Thu, Aug 25, 2022 at 3:03 PM Joe Conway wrote:
> Nice analysis, and surprising (to me)
Thanks.
> > I argue that #3 is a clear bug. robert can't select from stuff's
> > tables or change privileges on stuff's objects, so why can he change
> > stuff's default privileges? is_member_of_role() has
Robert Haas writes:
> I really hate back-patching this kind of change but it's possible that
> it's the right thing to do. There's no real security exposure because
> the member could always SET ROLE and then do the exact same thing, so
> back-patching feels to me like it has a significantly highe
On Thu, Aug 25, 2022 at 4:41 PM Tom Lane wrote:
> Yeah, I'd lean against back-patching. This is the sort of behavioral
> change that users tend not to like finding in minor releases.
Here's a small patch. Despite the small size of the patch, there are a
couple of debatable points here:
1. Shoul
Jeff Davis's comment in
http://postgr.es/m/4f8d536a9221bccc5a33bb784dace0ef2310ec4a.ca...@j-davis.com
reminds me that I need to update this thread based on the patch posted
over there. That patch allows you to grant membership in one role to
another while withholding the ability to SET ROLE to the
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> Jeff Davis's comment in
> http://postgr.es/m/4f8d536a9221bccc5a33bb784dace0ef2310ec4a.ca...@j-davis.com
> reminds me that I need to update this thread based on the patch posted
> over there. That patch allows you to grant membership in one
On Wed, Sep 7, 2022 at 5:51 PM Stephen Frost wrote:
> > To be more precise, I propose that in order for alice to create
> > objects owned by bob or to change one of her objects to be owned by
> > bob, she must not only be a member of role bob, but also inherit bob's
> > privileges. If she has the
Robert Haas:
Fairly obviously, my thinking here is biased by having written the
patch to allow restricting SET ROLE. If alice can neither inherit
bob's privileges nor SET ROLE bob, she had better not be able to
create objects owned by bob, because otherwise she can make a table,
add an expression
On Thu, Sep 8, 2022 at 11:45 AM Wolfgang Walther
wrote:
> I think to change the owner of an object from role A to role B, you just
> need a different "privilege" on that role B to "use" the role that way,
> which is distinct from INHERIT or SET ROLE "privileges".
It's not distinct, though, becaus
Robert Haas:
I think to change the owner of an object from role A to role B, you just
need a different "privilege" on that role B to "use" the role that way,
which is distinct from INHERIT or SET ROLE "privileges".
It's not distinct, though, because if you can transfer ownership of a
table to a
Robert Haas:
Fairly obviously, my thinking here is biased by having written the
patch to allow restricting SET ROLE. If alice can neither inherit
bob's privileges nor SET ROLE bob, she had better not be able to
create objects owned by bob, because otherwise she can make a table,
add an expression
On Fri, Aug 26, 2022 at 10:11 AM Robert Haas wrote:
> Here's a small patch. Despite the small size of the patch, there are a
> couple of debatable points here:
Nobody's commented on this patch specifically, but it seemed like we
had consensus that ALTER DEFAULT PRIVILEGES was doing The Wrong Thin
On Thu, Sep 8, 2022 at 1:06 PM wrote:
> A different line of thought (compared to the "USAGE" privilege I
> discussed earlier), would be:
> To transfer ownership of an object, you need two sets of privileges:
> - You need to have the privilege to initiate a request to transfer
> ownership.
> - You
26 matches
Mail list logo
