Re: REVOKE FROM warning on grantor - Mailing list pgsql-hackers

From Étienne BERSAC
Subject Re: REVOKE FROM warning on grantor
Date
Msg-id 5442bd74bbd6ce825d1d1ee9e1f91da4f4476dad.camel@dalibo.com
Whole thread Raw
In response to Re: REVOKE FROM warning on grantor  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: REVOKE FROM warning on grantor
List pgsql-hackers
Hi,

> https://dev.mysql.com/doc/refman/8.0/en/revoke.html documents an "IF
> EXISTS" option whose documentation reads, in relevant part,
> "Otherwise, REVOKE executes normally; if the user does not exist, the
> statement raises an error."
>
>
https://community.snowflake.com/s/article/Access-Control-Error-Message-When-Revoking-a-Non-existent-Role-Grant-From-a-Role-or-User
> is kind of interesting. It says that such commands used to fail with
> an error but that's been changed; now they don't.

It's not about inexistant user. It's not about inexistant membership.
It's about membership you are not allowed to revoke.

ldap2pg goals is to revoke spurious privileges. If ldap2pg find a
spurious membership, it revokes it. Postgres 16 does not revoke some
membership revoked before, and does not fail.

The usual case is: a superuser grants writers role to alice. In
directory, alice is degraded to readers. ldap2pg is not superuser but
has CREATEROLE. ldap2pg applies the changes. In Postgres 15, revocation
is completed. In Postgres 16, alice still has writers privileges and
ldap2pg is not aware of this without clunky checks.

Do you see a security concern here ?

Regards,
Étienne




pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Add Index-level REINDEX with multiple jobs
Next
From: Bruce Momjian
Date:
Subject: Re: documentation structure