| blob | 0db174e6f1065dd96a7d90dd28ccd46988479589 |
1 /*-------------------------------------------------------------------------
2 *
3 * user.c
4 * Commands for manipulating roles (formerly called users).
5 *
6 * Portions Copyright (c) 1996-2025, PostgreSQL Global Development Group
7 * Portions Copyright (c) 1994, Regents of the University of California
8 *
9 * src/backend/commands/user.c
10 *
11 *-------------------------------------------------------------------------
12 */
43 /*
44 * Removing a role grant - or the admin option on it - might recurse to
45 * dependent grants. We use these values to reason about what would need to
46 * be done in such cases.
47 *
48 * RRG_NOOP indicates a grant that would not need to be altered by the
49 * operation.
50 *
51 * RRG_REMOVE_ADMIN_OPTION indicates a grant that would need to have
52 * admin_option set to false by the operation.
53 *
54 * Similarly, RRG_REMOVE_INHERIT_OPTION and RRG_REMOVE_SET_OPTION indicate
55 * grants that would need to have the corresponding options set to false.
56 *
57 * RRG_DELETE_GRANT indicates a grant that would need to be removed entirely
58 * by the operation.
59 */
61 {
62 RRG_NOOP,
63 RRG_REMOVE_ADMIN_OPTION,
64 RRG_REMOVE_INHERIT_OPTION,
65 RRG_REMOVE_SET_OPTION,
66 RRG_DELETE_GRANT,
69 /* Potentially set by pg_upgrade_support functions */
73 {
80 #define GRANT_ROLE_SPECIFIED_ADMIN 0x0001
81 #define GRANT_ROLE_SPECIFIED_INHERIT 0x0002
82 #define GRANT_ROLE_SPECIFIED_SET 0x0004
84 /* GUC parameters */
90 /* Hook to check passwords in CreateRole() and AlterRole() */
99 DropBehavior behavior);
109 DropBehavior behavior);
116 DropBehavior behavior);
120 /* Check if current user has createrole privileges */
121 static bool
123 {
125 }
128 /*
129 * CREATE ROLE
130 */
131 Oid
133 {
134 Relation pg_authid_rel;
135 TupleDesc pg_authid_dsc;
136 HeapTuple tuple;
140 Oid roleid;
171 GrantRoleOptions popt;
173 /* The defaults can vary depending on the original statement type */
175 {
180 /* may eventually want inherit to default to false here */
184 }
186 /* Extract options from the statement node tree */
188 {
192 {
196 }
198 {
201 }
203 {
207 }
209 {
213 }
215 {
219 }
221 {
225 }
227 {
231 }
233 {
237 }
239 {
243 }
245 {
249 }
251 {
255 }
257 {
261 }
263 {
267 }
269 {
273 }
274 else
277 }
294 {
300 }
312 /* Check some permissions first */
314 {
345 }
347 /*
348 * Check that the user is not trying to create a role in the reserved
349 * "pg_" namespace.
350 */
358 /*
359 * If built with appropriate switch, whine when regression-testing
360 * conventions for role names are violated.
361 */
362 #ifdef ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS
364 elog(WARNING, "roles created by regression test cases should have names starting with \"regress_\"");
365 #endif
367 /*
368 * Check the pg_authid relation to be certain the role doesn't already
369 * exist.
370 */
380 /* Convert validuntil to internal form */
382 {
388 }
389 else
390 {
393 }
395 /*
396 * Call the password checking hook if there is one defined
397 */
400 password,
402 validUntil_datum,
403 validUntil_null);
405 /*
406 * Build a tuple to insert
407 */
419 {
423 /*
424 * Don't allow an empty password. Libpq treats an empty password the
425 * same as no password at all, and won't even try to authenticate. But
426 * other clients might, so allowing it would be confusing. By clearing
427 * the password when an empty string is specified, the account is
428 * consistently locked for all clients.
429 *
430 * Note that this only covers passwords stored in the database itself.
431 * There are also checks in the authentication code, to forbid an
432 * empty password from being used with authentication methods that
433 * fetch the password from an external system, like LDAP or PAM.
434 */
437 {
441 }
442 else
443 {
444 /* Encrypt the password to the requested format. */
446 password);
449 }
450 }
451 else
459 /*
460 * pg_largeobject_metadata contains pg_authid.oid's, so we use the
461 * binary-upgrade override.
462 */
464 {
472 }
473 else
474 {
476 Anum_pg_authid_oid);
477 }
483 /*
484 * Insert new record in the pg_authid table
485 */
488 /*
489 * Advance command counter so we can see new record; else tests in
490 * AddRoleMems may fail.
491 */
495 /* Default grant. */
498 /*
499 * Add the new role to the specified existing roles.
500 */
502 {
512 {
519 /* can only add this role to roles for which you have rights */
522 thisrole_list,
523 thisrole_oidlist,
527 }
528 }
530 /*
531 * If the current user isn't a superuser, make them an admin of the new
532 * role so that they can administer the new object they just created.
533 * Superusers will be able to do that anyway.
534 *
535 * The grantor of record for this implicit grant is the bootstrap
536 * superuser, which means that the CREATEROLE user cannot revoke the
537 * grant. They can however grant the created role back to themselves with
538 * different options, since they enjoy ADMIN OPTION on it.
539 */
541 {
543 GrantRoleOptions poptself;
552 | GRANT_ROLE_SPECIFIED_INHERIT
562 /*
563 * We must make the implicit grant visible to the code below, else the
564 * additional grants will fail.
565 */
568 /*
569 * Because of the implicit grant above, a CREATEROLE user who creates
570 * a role has the ability to grant that role back to themselves with
571 * the INHERIT or SET options, if they wish to inherit the role's
572 * privileges or be able to SET ROLE to it. The createrole_self_grant
573 * GUC can be used to make this happen automatically. This has no
574 * security implications since the same user is able to make the same
575 * grant using an explicit GRANT statement; it's just convenient.
576 */
581 }
583 /*
584 * Add the specified members to this new role. adminmembers get the admin
585 * option, rolemembers don't.
586 *
587 * NB: No permissions check is required here. If you have enough rights to
588 * create a role, you can add any members you like.
589 */
599 /* Post creation hook for new role */
602 /*
603 * Close pg_authid, but keep lock till commit.
604 */
608 }
611 /*
612 * ALTER ROLE
613 *
614 * Note: the rolemembers option accepted here is intended to support the
615 * backwards-compatible ALTER GROUP syntax. Although it will work to say
616 * "ALTER ROLE role ROLE rolenames", we don't document it.
617 */
618 Oid
620 {
624 Relation pg_authid_rel;
625 TupleDesc pg_authid_dsc;
626 HeapTuple tuple,
627 new_tuple;
628 Form_pg_authid authform;
647 Oid roleid;
649 GrantRoleOptions popt;
654 /* Extract options from the statement node tree */
656 {
660 {
664 }
666 {
670 }
672 {
676 }
678 {
682 }
684 {
688 }
690 {
694 }
696 {
700 }
702 {
706 }
709 {
713 }
715 {
719 }
721 {
725 }
726 else
729 }
734 {
740 }
744 /*
745 * Scan the pg_authid relation to be certain the user exists.
746 */
755 /* To mess with a superuser in any way you gotta be superuser. */
769 /*
770 * Most changes to a role require that you both have CREATEROLE privileges
771 * and also ADMIN OPTION on the role.
772 */
775 {
776 /* things an unprivileged user certainly can't do */
782 errdetail("Only roles with the %s attribute and the %s option on role \"%s\" may alter this role.",
785 /* an unprivileged user can change their own password */
790 errdetail("To change another role's password, the current user must have the %s attribute and the %s option on the role.",
792 }
794 {
795 /*
796 * Even if you have both CREATEROLE and ADMIN OPTION on a role, you
797 * can only change the CREATEDB, REPLICATION, or BYPASSRLS attributes
798 * if they are set for your own role (or you are the superuser).
799 */
818 }
820 /* To add or drop members, you need ADMIN OPTION. */
828 /* Convert validuntil to internal form */
830 {
836 }
837 else
838 {
839 /* fetch existing setting in case hook needs it */
841 Anum_pg_authid_rolvaliduntil,
843 }
845 /*
846 * Call the password checking hook if there is one defined
847 */
850 password,
852 validUntil_datum,
853 validUntil_null);
855 /*
856 * Build an updated tuple, perusing the information just obtained
857 */
859 /*
860 * issuper/createrole/etc
861 */
863 {
875 }
878 {
881 }
884 {
887 }
890 {
893 }
896 {
899 }
902 {
905 }
908 {
911 }
913 /* password */
915 {
919 /* Like in CREATE USER, don't allow an empty password. */
922 {
926 }
927 else
928 {
929 /* Encrypt the password to the requested format. */
931 password);
934 }
936 }
938 /* unset password */
940 {
943 }
945 /* valid until */
951 {
954 }
967 /*
968 * Advance command counter so we can see new record; else tests in
969 * AddRoleMems may fail.
970 */
972 {
985 }
987 /*
988 * Close pg_authid, but keep lock till commit.
989 */
993 }
996 /*
997 * ALTER ROLE ... SET
998 */
999 Oid
1001 {
1002 HeapTuple roletuple;
1003 Form_pg_authid roleform;
1008 {
1016 /*
1017 * Obtain a lock on the role and make sure it didn't go away in the
1018 * meantime.
1019 */
1022 /*
1023 * To mess with a superuser you gotta be superuser; otherwise you need
1024 * CREATEROLE plus admin option on the target role; unless you're just
1025 * trying to change your own settings
1026 */
1028 {
1035 }
1036 else
1037 {
1044 errdetail("Only roles with the %s attribute and the %s option on role \"%s\" may alter this role.",
1046 }
1049 }
1051 /* look up and lock the database, if specified */
1053 {
1058 {
1059 /*
1060 * If no role is specified, then this is effectively the same as
1061 * ALTER DATABASE ... SET, so use the same permission check.
1062 */
1066 }
1067 }
1070 {
1071 /* Must be superuser to alter settings globally. */
1078 }
1083 }
1086 /*
1087 * DROP ROLE
1088 */
1089 void
1091 {
1092 Relation pg_authid_rel,
1093 pg_auth_members_rel;
1101 errdetail("Only roles with the %s attribute and the %s option on the target roles may drop roles.",
1104 /*
1105 * Scan the pg_authid relation to find the Oid of the role(s) to be
1106 * deleted and perform preliminary permissions and sanity checks.
1107 */
1112 {
1115 HeapTuple tuple,
1116 tmp_tuple;
1117 Form_pg_authid roleform;
1118 ScanKeyData scankey;
1119 SysScanDesc sscan;
1120 Oid roleid;
1130 {
1132 {
1136 }
1137 else
1138 {
1141 role)));
1142 }
1145 }
1163 /*
1164 * For safety's sake, we allow createrole holders to drop ordinary
1165 * roles but not superuser roles, and only if they also have ADMIN
1166 * OPTION.
1167 */
1178 errdetail("Only roles with the %s attribute and the %s option on role \"%s\" may drop this role.",
1181 /* DROP hook for the role being removed */
1184 /* Don't leak the syscache tuple */
1187 /*
1188 * Lock the role, so nobody can add dependencies to her while we drop
1189 * her. We keep the lock until the end of transaction.
1190 */
1193 /*
1194 * If there is a pg_auth_members entry that has one of the roles to be
1195 * dropped as the roleid or member, it should be silently removed, but
1196 * if there is a pg_auth_members entry that has one of the roles to be
1197 * dropped as the grantor, the operation should fail.
1198 *
1199 * It's possible, however, that a single pg_auth_members entry could
1200 * fall into multiple categories - e.g. the user could do "GRANT foo
1201 * TO bar GRANTED BY baz" and then "DROP ROLE baz, bar". We want such
1202 * an operation to succeed regardless of the order in which the
1203 * to-be-dropped roles are passed to DROP ROLE.
1204 *
1205 * To make that work, we remove all pg_auth_members entries that can
1206 * be silently removed in this loop, and then below we'll make a
1207 * second pass over the list of roles to be removed and check for any
1208 * remaining dependencies.
1209 */
1211 Anum_pg_auth_members_roleid,
1219 {
1220 Form_pg_auth_members authmem_form;
1226 }
1231 Anum_pg_auth_members_member,
1239 {
1240 Form_pg_auth_members authmem_form;
1246 }
1250 /*
1251 * Advance command counter so that later iterations of this loop will
1252 * see the changes already made. This is essential if, for example,
1253 * we are trying to drop both a role and one of its direct members ---
1254 * we'll get an error if we try to delete the linking pg_auth_members
1255 * tuple twice. (We do not need a CCI between the two delete loops
1256 * above, because it's not allowed for a role to directly contain
1257 * itself.)
1258 */
1261 /* Looks tentatively OK, add it to the list if not there yet. */
1263 }
1265 /*
1266 * Second pass over the roles to be removed.
1267 */
1269 {
1271 HeapTuple tuple;
1272 Form_pg_authid roleform;
1276 /*
1277 * Re-find the pg_authid tuple.
1278 *
1279 * Since we've taken a lock on the role OID, it shouldn't be possible
1280 * for the tuple to have been deleted -- or for that matter updated --
1281 * unless the user is manually modifying the system catalogs.
1282 */
1288 /*
1289 * Check for pg_shdepend entries depending on this role.
1290 *
1291 * This needs to happen after we've completed removing any
1292 * pg_auth_members entries that can be removed silently, in order to
1293 * avoid spurious failures. See notes above for more details.
1294 */
1304 /*
1305 * Remove the role from the pg_authid table
1306 */
1311 /*
1312 * Remove any comments or security labels on this role.
1313 */
1317 /*
1318 * Remove settings for this role.
1319 */
1321 }
1323 /*
1324 * Now we can clean up; but keep locks until commit.
1325 */
1328 }
1330 /*
1331 * Rename role
1332 */
1333 ObjectAddress
1335 {
1336 HeapTuple oldtuple,
1337 newtuple;
1338 TupleDesc dsc;
1339 Relation rel;
1340 Datum datum;
1346 Oid roleid;
1347 ObjectAddress address;
1348 Form_pg_authid authform;
1359 /*
1360 * XXX Client applications probably store the session user somewhere, so
1361 * renaming it could cause confusion. On the other hand, there may not be
1362 * an actual problem besides a little confusion, so think about this and
1363 * decide. Same for SET ROLE ... we don't restrict renaming the current
1364 * effective userid, though.
1365 */
1379 /*
1380 * Check that the user is not trying to rename a system role and not
1381 * trying to rename a role into the reserved "pg_" namespace.
1382 */
1394 newname),
1397 /*
1398 * If built with appropriate switch, whine when regression-testing
1399 * conventions for role names are violated.
1400 */
1401 #ifdef ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS
1403 elog(WARNING, "roles created by regression test cases should have names starting with \"regress_\"");
1404 #endif
1406 /* make sure the new name doesn't exist */
1412 /*
1413 * Only superusers can mess with superusers. Otherwise, a user with
1414 * CREATEROLE can rename a role for which they have ADMIN OPTION.
1415 */
1417 {
1424 }
1425 else
1426 {
1432 errdetail("Only roles with the %s attribute and the %s option on role \"%s\" may rename this role.",
1434 }
1436 /* OK, construct the modified tuple */
1448 {
1449 /* MD5 uses the username as salt, so just clear it on a rename */
1455 }
1466 /*
1467 * Close pg_authid, but keep lock till commit.
1468 */
1472 }
1474 /*
1475 * GrantRoleStmt
1476 *
1477 * Grant/Revoke roles to/from roles
1478 */
1479 void
1481 {
1482 Relation pg_authid_rel;
1483 Oid grantor;
1486 GrantRoleOptions popt;
1489 /* Parse options list. */
1492 {
1497 {
1502 }
1504 {
1508 }
1510 {
1514 }
1515 else
1526 }
1528 /* Lookup OID of grantor, if specified. */
1531 else
1536 /* AccessShareLock is enough since we aren't modifying pg_authid */
1539 /*
1540 * Step through all of the granted roles and add, update, or remove
1541 * entries in pg_auth_members as appropriate. If stmt->is_grant is true,
1542 * we are adding new grants or, if they already exist, updating options on
1543 * those grants. If stmt->is_grant is false, we are revoking grants or
1544 * removing options from them.
1545 */
1547 {
1550 Oid roleid;
1552 /* Must reject priv(columns) and ALL PRIVILEGES(columns) */
1565 else
1569 }
1571 /*
1572 * Close pg_authid, but keep lock till commit.
1573 */
1575 }
1577 /*
1578 * DropOwnedObjects
1579 *
1580 * Drop the objects owned by a given list of roles.
1581 */
1582 void
1584 {
1588 /* Check privileges */
1590 {
1599 }
1601 /* Ok, do it */
1603 }
1605 /*
1606 * ReassignOwnedObjects
1607 *
1608 * Give the objects owned by a given list of roles away to another user.
1609 */
1610 void
1612 {
1615 Oid newrole;
1617 /* Check privileges */
1619 {
1628 }
1630 /* Must have privileges on the receiving side too */
1640 /* Ok, do it */
1642 }
1644 /*
1645 * roleSpecsToIds
1646 *
1647 * Given a list of RoleSpecs, generate a list of role OIDs in the same order.
1648 *
1649 * ROLESPEC_PUBLIC is not allowed.
1650 */
1651 List *
1653 {
1658 {
1660 Oid roleid;
1664 }
1666 }
1668 /*
1669 * AddRoleMems -- Add given members to the specified role
1670 *
1671 * currentUserId: OID of role performing the operation
1672 * rolename: name of role to add to (used only for error messages)
1673 * roleid: OID of role to add to
1674 * memberSpecs: list of RoleSpec of roles to add (used only for error messages)
1675 * memberIds: OIDs of roles to add
1676 * grantorId: OID that should be recorded as having granted the membership
1677 * (InvalidOid if not set explicitly)
1678 * popt: information about grant options
1679 */
1680 static void
1684 {
1685 Relation pg_authmem_rel;
1686 TupleDesc pg_authmem_dsc;
1692 /* Validate grantor (and resolve implicit grantor if not specified). */
1698 /*
1699 * Only allow changes to this role by one backend at a time, so that we
1700 * can check integrity constraints like the lack of circular ADMIN OPTION
1701 * grants without fear of race conditions.
1702 */
1704 ShareUpdateExclusiveLock);
1706 /* Preliminary sanity checks. */
1708 {
1712 /*
1713 * pg_database_owner is never a role member. Lifting this restriction
1714 * would require a policy decision about membership loops. One could
1715 * prevent loops, which would include making "ALTER DATABASE x OWNER
1716 * TO proposed_datdba" fail if is_member_of_role(pg_database_owner,
1717 * proposed_datdba). Hence, gaining a membership could reduce what a
1718 * role could do. Alternately, one could allow these memberships to
1719 * complete loops. A role could then have actual WITH ADMIN OPTION on
1720 * itself, prompting a decision about is_admin_of_role() treatment of
1721 * the case.
1722 *
1723 * Lifting this restriction also has policy implications for ownership
1724 * of shared objects (databases and tablespaces). We allow such
1725 * ownership, but we might find cause to ban it in the future.
1726 * Designing such a ban would more troublesome if the design had to
1727 * address pg_database_owner being a member of role FOO that owns a
1728 * shared object. (The effect of such ownership is that any owner of
1729 * another database can act as the owner of affected shared objects.)
1730 */
1737 /*
1738 * Refuse creation of membership loops, including the trivial case
1739 * where a role is made a member of itself. We do this by checking to
1740 * see if the target role is already a member of the proposed member
1741 * role. We have to ignore possible superuserness, however, else we
1742 * could never grant membership in a superuser-privileged role.
1743 */
1749 }
1751 /*
1752 * Disallow attempts to grant ADMIN OPTION back to a user who granted it
1753 * to you, similar to what check_circularity does for ACLs. We want the
1754 * chains of grants to remain acyclic, so that it's always possible to use
1755 * REVOKE .. CASCADE to clean up all grants that depend on the one being
1756 * revoked.
1757 *
1758 * NB: This check might look redundant with the check for membership loops
1759 * above, but it isn't. That's checking for role-member loop (e.g. A is a
1760 * member of B and B is a member of A) while this is checking for a
1761 * member-grantor loop (e.g. A gave ADMIN OPTION on X to B and now B, who
1762 * has no other source of ADMIN OPTION on X, tries to give ADMIN OPTION on
1763 * X back to A).
1764 */
1766 {
1771 /* Get the list of members for this role. */
1775 /*
1776 * Figure out what would happen if we removed all existing grants to
1777 * every role to which we've been asked to make a new grant.
1778 */
1781 {
1790 }
1792 /*
1793 * If the result would be that the grantor role would no longer have
1794 * the ability to perform the grant, then the proposed grant would
1795 * create a circularity.
1796 */
1798 {
1799 HeapTuple authmem_tuple;
1800 Form_pg_auth_members authmem_form;
1809 }
1817 }
1819 /* Now perform the catalog updates. */
1821 {
1824 HeapTuple authmem_tuple;
1825 HeapTuple tuple;
1830 /* Common initialization for possible insert or update */
1838 /* Find any existing tuple */
1844 /*
1845 * If we found a tuple, update it with new option values, unless there
1846 * are no changes, in which case issue a WARNING.
1847 *
1848 * If we didn't find a tuple, just insert one.
1849 */
1851 {
1852 Form_pg_auth_members authmem_form;
1859 {
1865 }
1869 {
1875 }
1879 {
1885 }
1888 {
1895 }
1898 new_record,
1903 }
1904 else
1905 {
1906 Oid objectId;
1909 /*
1910 * The values for these options can be taken directly from 'popt'.
1911 * Either they were specified, or the defaults as set by
1912 * InitGrantRoleOptions are correct.
1913 */
1919 /*
1920 * If the user specified a value for the inherit option, use
1921 * whatever was specified. Otherwise, set the default value based
1922 * on the role-level property.
1923 */
1927 else
1928 {
1929 HeapTuple mrtup;
1930 Form_pg_authid mrform;
1939 }
1941 /* get an OID for the new row and insert it */
1943 Anum_pg_auth_members_oid);
1949 /* updateAclDependencies wants to pfree array inputs */
1955 }
1957 /* CCI after each change, in case there are duplicates in list */
1959 }
1961 /*
1962 * Close pg_authmem, but keep lock till commit.
1963 */
1965 }
1967 /*
1968 * DelRoleMems -- Remove given members from the specified role
1969 *
1970 * rolename: name of role to del from (used only for error messages)
1971 * roleid: OID of role to del from
1972 * memberSpecs: list of RoleSpec of roles to del (used only for error messages)
1973 * memberIds: OIDs of roles to del
1974 * grantorId: who is revoking the membership
1975 * popt: information about grant options
1976 * behavior: RESTRICT or CASCADE behavior for recursive removal
1977 */
1978 static void
1982 {
1983 Relation pg_authmem_rel;
1984 TupleDesc pg_authmem_dsc;
1993 /* Validate grantor (and resolve implicit grantor if not specified). */
1999 /*
2000 * Only allow changes to this role by one backend at a time, so that we
2001 * can check for things like dependent privileges without fear of race
2002 * conditions.
2003 */
2005 ShareUpdateExclusiveLock);
2010 /*
2011 * We may need to recurse to dependent privileges if DROP_CASCADE was
2012 * specified, or refuse to perform the operation if dependent privileges
2013 * exist and DROP_RESTRICT was specified. plan_single_revoke() will figure
2014 * out what to do with each catalog tuple.
2015 */
2017 {
2023 {
2029 }
2030 }
2032 /*
2033 * We now know what to do with each catalog tuple: it should either be
2034 * left alone, deleted, or just have the admin_option flag cleared.
2035 * Perform the appropriate action in each case.
2036 */
2038 {
2039 HeapTuple authmem_tuple;
2040 Form_pg_auth_members authmem_form;
2049 {
2050 /*
2051 * Remove the entry altogether, after first removing its
2052 * dependencies
2053 */
2057 }
2058 else
2059 {
2060 /* Just turn off the specified option */
2061 HeapTuple tuple;
2066 /* Build a tuple to update with */
2068 {
2073 }
2075 {
2080 }
2082 {
2087 }
2088 else
2092 new_record,
2095 }
2096 }
2100 /*
2101 * Close pg_authmem, but keep lock till commit.
2102 */
2104 }
2106 /*
2107 * Check that currentUserId has permission to modify the membership list for
2108 * roleid. Throw an error if not.
2109 */
2110 static void
2113 {
2114 /*
2115 * The charter of pg_database_owner is to have exactly one, implicit,
2116 * situation-dependent member. There's no technical need for this
2117 * restriction. (One could lift it and take the further step of making
2118 * object_ownercheck(DatabaseRelationId, ...) equivalent to
2119 * has_privs_of_role(roleid, ROLE_PG_DATABASE_OWNER), in which case
2120 * explicit, situation-independent members could act as the owner of any
2121 * database.)
2122 */
2129 /* To mess with a superuser role, you gotta be superuser. */
2131 {
2133 {
2141 else
2148 }
2149 }
2150 else
2151 {
2152 /*
2153 * Otherwise, must have admin option on the role to be changed.
2154 */
2156 {
2164 else
2171 }
2172 }
2173 }
2175 /*
2176 * Sanity-check, or infer, the grantor for a GRANT or REVOKE statement
2177 * targeting a role.
2178 *
2179 * The grantor must always be either a role with ADMIN OPTION on the role in
2180 * which membership is being granted, or the bootstrap superuser. This is
2181 * similar to the restriction enforced by select_best_grantor, except that
2182 * roles don't have owners, so we regard the bootstrap superuser as the
2183 * implicit owner.
2184 *
2185 * If the grantor was not explicitly specified by the user, grantorId should
2186 * be passed as InvalidOid, and this function will infer the user to be
2187 * recorded as the grantor. In many cases, this will be the current user, but
2188 * things get more complicated when the current user doesn't possess ADMIN
2189 * OPTION on the role but rather relies on having SUPERUSER privileges, or
2190 * on inheriting the privileges of a role which does have ADMIN OPTION. See
2191 * below for details.
2192 *
2193 * If the grantor was specified by the user, then it must be a user that
2194 * can legally be recorded as the grantor, as per the rule stated above.
2195 * This is an integrity constraint, not a permissions check, and thus even
2196 * superusers are subject to this restriction. However, there is also a
2197 * permissions check: to specify a role as the grantor, the current user
2198 * must possess the privileges of that role. Superusers will always pass
2199 * this check, but for non-superusers it may lead to an error.
2200 *
2201 * The return value is the OID to be regarded as the grantor when executing
2202 * the operation.
2203 */
2204 static Oid
2206 {
2207 /* If the grantor ID was not specified, pick one to use. */
2209 {
2210 /*
2211 * Grants where the grantor is recorded as the bootstrap superuser do
2212 * not depend on any other existing grants, so always default to this
2213 * interpretation when possible.
2214 */
2218 /*
2219 * Otherwise, the grantor must either have ADMIN OPTION on the role or
2220 * inherit the privileges of a role which does. In the former case,
2221 * record the grantor as the current user; in the latter, pick one of
2222 * the roles that is "most directly" inherited by the current role
2223 * (i.e. fewest "hops").
2224 *
2225 * (We shouldn't fail to find a best grantor, because we've already
2226 * established that the current user has permission to perform the
2227 * operation.)
2228 */
2233 }
2235 /*
2236 * If an explicit grantor is specified, it must be a role whose privileges
2237 * the current user possesses.
2238 *
2239 * It should also be a role that has ADMIN OPTION on the target role, but
2240 * we check this condition only in case of GRANT. For REVOKE, no matching
2241 * grant should exist anyway, but if it somehow does, let the user get rid
2242 * of it.
2243 */
2245 {
2262 }
2263 else
2264 {
2270 errdetail("Only roles with privileges of role \"%s\" may revoke privileges granted by this role.",
2272 }
2274 /*
2275 * If a grantor was specified explicitly, always attribute the grant to
2276 * that role (unless we error out above).
2277 */
2279 }
2281 /*
2282 * Initialize an array of RevokeRoleGrantAction objects.
2283 *
2284 * 'memlist' should be a list of all grants for the target role.
2285 *
2286 * This constructs an array indicating that no actions are to be performed;
2287 * that is, every element is initially RRG_NOOP.
2288 */
2291 {
2302 }
2304 /*
2305 * Figure out what we would need to do in order to revoke a grant, or just the
2306 * admin option on a grant, given that there might be dependent privileges.
2307 *
2308 * 'memlist' should be a list of all grants for the target role.
2309 *
2310 * Whatever actions prove to be necessary will be signalled by updating
2311 * 'actions'.
2312 *
2313 * If behavior is DROP_RESTRICT, an error will occur if there are dependent
2314 * role membership grants; if DROP_CASCADE, those grants will be scheduled
2315 * for deletion.
2316 *
2317 * The return value is true if the matching grant was found in the list,
2318 * and false if not.
2319 */
2320 static bool
2323 DropBehavior behavior)
2324 {
2327 /*
2328 * If popt.specified == 0, we're revoking the grant entirely; otherwise,
2329 * we expect just one bit to be set, and we're revoking the corresponding
2330 * option. As of this writing, there's no syntax that would allow for an
2331 * attempt to revoke multiple options at once, and the logic below
2332 * wouldn't work properly if such syntax were added, so assert that our
2333 * caller isn't trying to do that.
2334 */
2338 {
2339 HeapTuple authmem_tuple;
2340 Form_pg_auth_members authmem_form;
2347 {
2349 {
2350 /*
2351 * Revoking the INHERIT option doesn't change anything for
2352 * dependent privileges, so we don't need to recurse.
2353 */
2355 }
2357 {
2358 /* Here too, no need to recurse. */
2360 }
2361 else
2362 {
2365 /*
2366 * Revoking the grant entirely, or ADMIN option on a grant,
2367 * implicates dependent privileges, so we may need to recurse.
2368 */
2369 revoke_admin_option_only =
2373 }
2375 }
2376 }
2379 }
2381 /*
2382 * Figure out what we would need to do in order to revoke all grants to
2383 * a given member, given that there might be dependent privileges.
2384 *
2385 * 'memlist' should be a list of all grants for the target role.
2386 *
2387 * Whatever actions prove to be necessary will be signalled by updating
2388 * 'actions'.
2389 */
2390 static void
2392 Oid member)
2393 {
2397 {
2398 HeapTuple authmem_tuple;
2399 Form_pg_auth_members authmem_form;
2406 }
2407 }
2409 /*
2410 * Workhorse for figuring out recursive revocation of role grants.
2411 *
2412 * This is similar to what recursive_revoke() does for ACLs.
2413 */
2414 static void
2418 {
2420 HeapTuple authmem_tuple;
2421 Form_pg_auth_members authmem_form;
2424 /* If it's already been done, we can just return. */
2428 revoke_admin_option_only)
2431 /* Locate tuple data. */
2435 /*
2436 * If the existing tuple does not have admin_option set, then we do not
2437 * need to recurse. If we're just supposed to clear that bit we don't need
2438 * to do anything at all; if we're supposed to remove the grant, we need
2439 * to do something, but only to the tuple, and not any others.
2440 */
2442 {
2446 }
2447 else
2448 {
2452 }
2454 /* Determine whether the member would still have ADMIN OPTION. */
2456 {
2457 HeapTuple am_cascade_tuple;
2458 Form_pg_auth_members am_cascade_form;
2465 {
2468 }
2469 }
2471 /* If the member would still have ADMIN OPTION, we need not recurse. */
2475 /*
2476 * Recurse to grants that are not yet slated for deletion which have this
2477 * member as the grantor.
2478 */
2480 {
2481 HeapTuple am_cascade_tuple;
2482 Form_pg_auth_members am_cascade_form;
2489 {
2497 }
2498 }
2499 }
2501 /*
2502 * Initialize a GrantRoleOptions object with default values.
2503 */
2504 static void
2506 {
2511 }
2513 /*
2514 * GUC check_hook for createrole_self_grant
2515 */
2516 bool
2518 {
2525 /* Need a modifiable copy of string */
2529 {
2530 /* syntax error in list */
2535 }
2538 {
2545 else
2546 {
2551 }
2552 }
2562 }
2564 /*
2565 * GUC assign_hook for createrole_self_grant
2566 */
2567 void
2569 {
2574 | GRANT_ROLE_SPECIFIED_INHERIT
2581 }