mirror of
https://github.com/postgres/postgres.git
synced 2026-03-27 12:54:24 -04:00
ce6b672e44
Previously, membership of role A in role B could be recorded in the catalog tables only once. This meant that a new grant of role A to role B would overwrite the previous grant. For other object types, a new grant of permission on an object - in this case role A - exists along side the existing grant provided that the grantor is different. Either grant can be revoked independently of the other, and permissions remain so long as at least one grant remains. Make role grants work similarly. Previously, when granting membership in a role, the superuser could specify any role whatsoever as the grantor, but for other object types, the grantor of record must be either the owner of the object, or a role that currently has privileges to perform a similar GRANT. Implement the same scheme for role grants, treating the bootstrap superuser as the role owner since roles do not have owners. This means that attempting to revoke a grant, or admin option on a grant, can now fail if there are dependent privileges, and that CASCADE can be used to revoke these. It also means that you can't grant ADMIN OPTION on a role back to a user who granted it directly or indirectly to you, similar to how you can't give WITH GRANT OPTION on a privilege back to a role which granted it directly or indirectly to you. Previously, only the superuser could specify GRANTED BY with a user other than the current user. Relax that rule to allow the grantor to be any role whose privileges the current user posseses. This doesn't improve compatibility with what we do for other object types, where support for GRANTED BY is entirely vestigial, but it makes this feature more usable and seems to make sense to change at the same time we're changing related behaviors. Along the way, fix "ALTER GROUP group_name ADD USER user_name" to require the same privileges as "GRANT group_name TO user_name". Previously, CREATEROLE privileges were sufficient for either, but only the former form was permissible with ADMIN OPTION on the role. Now, either CREATEROLE or ADMIN OPTION on the role suffices for either spelling. Patch by me, reviewed by Stephen Frost. Discussion: http://postgr.es/m/CA+TgmoaFr-RZeQ+WoQ5nKPv97oT9+aDgK_a5+qWHSgbDsMp1Vg@mail.gmail.com |
||
|---|---|---|
| .. | ||
| activity | ||
| adt | ||
| cache | ||
| error | ||
| fmgr | ||
| hash | ||
| init | ||
| mb | ||
| misc | ||
| mmgr | ||
| resowner | ||
| sort | ||
| time | ||
| .gitignore | ||
| errcodes.txt | ||
| Gen_dummy_probes.pl | ||
| Gen_dummy_probes.pl.prolog | ||
| Gen_dummy_probes.sed | ||
| Gen_fmgrtab.pl | ||
| generate-errcodes.pl | ||
| Makefile | ||
| postprocess_dtrace.sed | ||
| probes.d | ||
| README.Gen_dummy_probes | ||
# Generating dummy probes If Postgres isn't configured with dtrace enabled, we need to generate dummy probes for the entries in probes.d, that do nothing. This is accomplished in Unix via the sed script `Gen_dummy_probes.sed`. We used to use this in MSVC builds using the perl utility `psed`, which mimicked sed. However, that utility disappeared from Windows perl distributions and so we converted the sed script to a perl script to be used in MSVC builds. We still keep the sed script as the authoritative source for generating these dummy probes because except on Windows perl is not a hard requirement when building from a tarball. So, if you need to change the way dummy probes are generated, first change the sed script, and when it's working generate the perl script. This can be accomplished by using the perl utility s2p. s2p is no longer part of the perl core, so it might not be on your system, but it is available on CPAN and also in many package systems. e.g. on Fedora it can be installed using `cpan App::s2p` or `dnf install perl-App-s2p`. The Makefile contains a recipe for regenerating Gen_dummy_probes.pl, so all you need to do is once you have s2p installed is `make Gen_dummy_probes.pl` Note that in a VPATH build this will generate the file in the vpath tree, not the source tree.