Re: has_privs_of_role vs. is_member_of_role, redux

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 such a change being accepted are approximately zero.
> Inheriting privileges needs to keep meaning what it means now, namely,
> you inherit all the rights of the granted role.

No. Inheriting stays the same, it's just WITH SET that's different from
what it is "now".

> I don't. And even if I did think it were easy to explain, I don't
> think it would be a good idea. One of my first patches to PostgreSQL
> added a grantable TRUNCATE privilege to tables. I think that, under
> your proposed definitions, the addition of this privilege would have
> had the result that a role grant would cease to allow the recipient to
> truncate tables owned by the granted role. There is currently a
> proposal on the table to make VACUUM and ANALYZE grantable permissions
> on tables, which would have the same issue. I think that if I made it
> so that adding such privileges resulted in role inheritance not
> working for those operations any more, people would come after me with
> pitchforks. And I wouldn't blame them: that sounds terrible.

No, there is a misunderstanding. In my proposal, when you do WITH SET
TRUE everything stays exactly the same as it is right now.

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 roles.

Could be discussed in the WITH SET thread, but it's a natural extension
of the categories (1) and (2) in your original email. It's all about
ownership.

Best

Wolfgang