public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: Robert Haas <[email protected]>
To: Joe Conway <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Bossart, Nathan <[email protected]>
Cc: Stephen Frost <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: replacing role-level NOINHERIT with a grant-level option
Date: Fri, 10 Jun 2022 22:36:27 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+Tgmoax3J2D1RoqSqBRuLVifMjinZ5SPvR+rBqBT89u57zOJQ@mail.gmail.com>
References: <CAGB+Vh4Zv_TvKt2tv3QNS6tUM_F_9icmuj0zjywwcgVi4PAhFA@mail.gmail.com>
<CA+TgmobiMfUoZ42ZDz_6Ne4zMznOjxfEb22W+jdNX29yL88agw@mail.gmail.com>
<CAGB+Vh4cCTey_TvE_O0CZu-D+6fVXC8a+C-UTzqkg8oN5YcOrQ@mail.gmail.com>
<CAGB+Vh7fgOfLtCG+01D8ch3icG2aEd38dvy9uavtKWrpf1_XZw@mail.gmail.com>
<[email protected]>
<CAGB+Vh5RpzZroX-RKLXYWyTidpWX6=qcbMoVWERotAWh-_CeUQ@mail.gmail.com>
<[email protected]>
<CAGB+Vh4Om+DFD2KChk5bjz+F2c+AJWDdPqiKPNxf5Ld3CvwwFw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAGB+Vh4jWh-KuV6qt0FKC3M=HCZT1X=Kn5E1g68s1+0OSfoCdQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+TgmoYeNB1PxMO-TYv4_Ky7XR3-3Le+fpL87T7QMR=OWc7U1Q@mail.gmail.com>
<[email protected]>
<CA+Tgmoax3J2D1RoqSqBRuLVifMjinZ5SPvR+rBqBT89u57zOJQ@mail.gmail.com>
On 02.06.22 18:26, Robert Haas wrote:
> On Mon, Feb 7, 2022 at 11:13 AM Joe Conway<[email protected]> wrote:
>>> It seems to me that the INHERIT role flag isn't very well-considered.
>>> Inheritance, or the lack of it, ought to be decided separately for
>>> each inherited role. However, that would be a major architectural
>>> change.
>> Agreed -- that would be useful.
> Is this a kind of change people would support?
I think this would create a conflict with what role-based access control
normally means (outside of PostgreSQL specifically). A role is a
collection of privileges that you dynamically enable (e.g., with SET
ROLE). That corresponds to the NOINHERIT behavior. It's also what the
SQL standard specifies (which in term references other standards for
RBAC). The INHERIT behavior basically emulates the groups that used to
exist in PostgreSQL.
There are also possibly other properties you could derive from that
distinction. For example, you could argue that something like
pg_hba.conf should have group matching but not (noinherit-)role
matching, since those roles are not actually activated all the time.
There are also more advanced concepts like roles that are mutually
exclusive so that you can't activate them both at once.
Now, what PostgreSQL currently implements is a bit of a mess that's a
somewhat incompatible subset of all that. But you can basically get
those standard behaviors somehow. So I don't think we should break this
and go into a totally opposite direction.
view thread (74+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: replacing role-level NOINHERIT with a grant-level option
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox