summaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorNoah Misch2014-02-17 14:33:31 +0000
committerNoah Misch2014-02-17 14:33:33 +0000
commit15a8f97b9d16aaf659f58c981242b9da591cf24c (patch)
treee1903eef5a2ddab3eb22af70e273d45daa64362c /doc/src
parent9649892c330429b86751f8eb37182e31018134f7 (diff)
Shore up ADMIN OPTION restrictions.
Granting a role without ADMIN OPTION is supposed to prevent the grantee from adding or removing members from the granted role. Issuing SET ROLE before the GRANT bypassed that, because the role itself had an implicit right to add or remove members. Plug that hole by recognizing that implicit right only when the session user matches the current role. Additionally, do not recognize it during a security-restricted operation or during execution of a SECURITY DEFINER function. The restriction on SECURITY DEFINER is not security-critical. However, it seems best for a user testing his own SECURITY DEFINER function to see the same behavior others will see. Back-patch to 8.4 (all supported versions). The SQL standards do not conflate roles and users as PostgreSQL does; only SQL roles have members, and only SQL users initiate sessions. An application using PostgreSQL users and roles as SQL users and roles will never attempt to grant membership in the role that is the session user, so the implicit right to add or remove members will never arise. The security impact was mostly that a role member could revoke access from others, contrary to the wishes of his own grantor. Unapproved role member additions are less notable, because the member can still largely achieve that by creating a view or a SECURITY DEFINER function. Reviewed by Andres Freund and Tom Lane. Reported, independently, by Jonas Sundman and Noah Misch. Security: CVE-2014-0060
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/ref/grant.sgml12
1 files changed, 7 insertions, 5 deletions
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index fb81af425da..2b5a84388c4 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -396,11 +396,13 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
<para>
If <literal>WITH ADMIN OPTION</literal> is specified, the member can
in turn grant membership in the role to others, and revoke membership
- in the role as well. Without the admin option, ordinary users cannot do
- that. However,
- database superusers can grant or revoke membership in any role to anyone.
- Roles having <literal>CREATEROLE</> privilege can grant or revoke
- membership in any role that is not a superuser.
+ in the role as well. Without the admin option, ordinary users cannot
+ do that. A role is not considered to hold <literal>WITH ADMIN
+ OPTION</literal> on itself, but it may grant or revoke membership in
+ itself from a database session where the session user matches the
+ role. Database superusers can grant or revoke membership in any role
+ to anyone. Roles having <literal>CREATEROLE</> privilege can grant
+ or revoke membership in any role that is not a superuser.
</para>
<para>