Shore up ADMIN OPTION restrictions.
authorNoah Misch <noah@leadboat.com>
Mon, 17 Feb 2014 14:33:31 +0000 (09:33 -0500)
committerNoah Misch <noah@leadboat.com>
Mon, 17 Feb 2014 14:33:31 +0000 (09:33 -0500)
commitfea164a72a7bfd50d77ba5fb418d357f8f2bb7d0
treedecfbae5e3c54de074a6cd47fa60344b892e5bf7
parent0983315b1d37cc17b2174dad87449d8402e357ee
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
doc/src/sgml/ref/grant.sgml
src/backend/commands/user.c
src/backend/utils/adt/acl.c
src/test/regress/expected/privileges.out
src/test/regress/sql/privileges.sql