"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Jul 8, 2024 at 3:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That doesn't make it not a bug.
> Fair, the code was from a time when membership implied SET permission which
> apparently was, IMO, still is, a sufficient reason to allow a member of
> that group to login.
> By making SET optional we removed this presumption and broke this code and
> now need to decide what is a valid setup to allow logging in. So, yes, a
> bug.
Yeah, that's what I'm thinking --- I also think the current behavior
was an oversight rather than an intentional decision. Possibly Robert
remembers differently though.
> So long as we document that being a member of a group grants you the right
> to login if that group is named in pg_hba.conf I don't see how that is an
> invalid specification. It also isn't self-evidently correct. If we do
> agree that the status quo is undesirable the change I'd expect is to
> require at least one of the membership options to be true in order to be
> allowed to login.
I'd argue that INHERIT TRUE should be required. The point of SET TRUE
with INHERIT FALSE is that you must *explicitly* do SET ROLE or
equivalent in order to have access to the privileges of the referenced
role. There is no opportunity to issue SET ROLE before logging in,
but ISTM that means you don't get the privilege, not that you
magically get it without asking. Otherwise, why did we build this
additional level of grant specificity at all?
I follow the use-case of wanting to be able to log into a database
where your only useful privileges are locked behind SET requirements.
But I'd still argue that you should need to be able to log into that
database using your own privileges. An analogous case is that having
some privileges on table(s) in some schema does not give you the right
to bypass needing USAGE on the schema in order to access those tables.
> I wish we could break even
> allowing all-false as an active state but that seems too late to try and
> do.
I suppose that was intentional, but I too wonder about the use-case.
I guess it's analogous to, for example, zero-column tables. That is,
it's not terribly useful as a static state but it might be a state
you pass through in a series of manipulations. Forbidding it would
just create a roadblock that'd have to be worked around, for example
by being very careful about the ordering of GRANT/REVOKE commands.
regards, tom lane