Perform logical replication actions as the table owner.
Up until now, logical replication actions have been performed as the
subscription owner, who will generally be a superuser. Commit
cec57b1a0fbcd3833086ba686897c5883e0a2afc documented hazards
associated with that situation, namely, that any user who owns a
table on the subscriber side could assume the privileges of the
subscription owner by attaching a trigger, expression index, or
some other kind of executable code to it. As a remedy, it suggested
not creating configurations where users who are not fully trusted
own tables on the subscriber.
Although that will work, it basically precludes using logical
replication in the way that people typically want to use it,
namely, to replicate a database from one node to another
without necessarily having any restrictions on which database
users can own tables. So, instead, change logical replication to
execute INSERT, UPDATE, DELETE, and TRUNCATE operations as the
table owner when they are replicated.
Since this involves switching the active user frequently within
a session that is authenticated as the subscription user, also
impose SECURITY_RESTRICTED_OPERATION restrictions on logical
replication code. As an exception, if the table owner can SET
ROLE to the subscription owner, these restrictions have no
security value, so don't impose them in that case.
Subscription owners are now required to have the ability to
SET ROLE to every role that owns a table that the subscription
is replicating. If they don't, replication will fail. Superusers,
who normally own subscriptions, satisfy this property by default.
Non-superusers users who own subscriptions will need to be
granted the roles that own relevant tables.
Patch by me, reviewed (but not necessarily in its entirety) by
Jelte Fennema, Jeff Davis, and Noah Misch.
Discussion: http://postgr.es/m/CA+TgmoaSCkg9ww9oppPqqs+9RVqCexYCE6Aq=UsYPfnOoDeFkw@mail.gmail.com
2023-04-04 17:25:23 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* usercontext.c
|
|
|
|
* Convenience functions for running code as a different database user.
|
|
|
|
*
|
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/backend/utils/init/usercontext.c
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "miscadmin.h"
|
|
|
|
#include "utils/acl.h"
|
|
|
|
#include "utils/guc.h"
|
|
|
|
#include "utils/usercontext.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Temporarily switch to a new user ID.
|
|
|
|
*
|
|
|
|
* If the current user doesn't have permission to SET ROLE to the new user,
|
|
|
|
* an ERROR occurs.
|
|
|
|
*
|
|
|
|
* If the new user doesn't have permission to SET ROLE to the current user,
|
|
|
|
* SECURITY_RESTRICTED_OPERATION is imposed and a new GUC nest level is
|
|
|
|
* created so that any settings changes can be rolled back.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
SwitchToUntrustedUser(Oid userid, UserContext *context)
|
|
|
|
{
|
|
|
|
/* Get the current user ID and security context. */
|
|
|
|
GetUserIdAndSecContext(&context->save_userid,
|
|
|
|
&context->save_sec_context);
|
|
|
|
|
|
|
|
/* Check that we have sufficient privileges to assume the target role. */
|
|
|
|
if (!member_can_set_role(context->save_userid, userid))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
|
|
|
errmsg("role \"%s\" cannot SET ROLE to \"%s\"",
|
|
|
|
GetUserNameFromId(context->save_userid, false),
|
|
|
|
GetUserNameFromId(userid, false))));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to prevent the user to which we're switching from assuming the
|
|
|
|
* privileges of the current user, unless they can SET ROLE to that user
|
|
|
|
* anyway.
|
|
|
|
*/
|
|
|
|
if (member_can_set_role(userid, context->save_userid))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Each user can SET ROLE to the other, so there's no point in
|
|
|
|
* imposing any security restrictions. Just let the user do whatever
|
|
|
|
* they want.
|
|
|
|
*/
|
|
|
|
SetUserIdAndSecContext(userid, context->save_sec_context);
|
|
|
|
context->save_nestlevel = -1;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
int sec_context = context->save_sec_context;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This user can SET ROLE to the target user, but not the other way
|
|
|
|
* around, so protect ourselves against the target user by setting
|
|
|
|
* SECURITY_RESTRICTED_OPERATION to prevent certain changes to the
|
|
|
|
* session state. Also set up a new GUC nest level, so that we can
|
|
|
|
* roll back any GUC changes that may be made by code running as the
|
|
|
|
* target user, inasmuch as they could be malicious.
|
|
|
|
*/
|
|
|
|
sec_context |= SECURITY_RESTRICTED_OPERATION;
|
|
|
|
SetUserIdAndSecContext(userid, sec_context);
|
|
|
|
context->save_nestlevel = NewGUCNestLevel();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Switch back to the original user ID.
|
|
|
|
*
|
2023-04-05 15:50:08 +02:00
|
|
|
* If we created a new GUC nest level, also roll back any changes that were
|
Perform logical replication actions as the table owner.
Up until now, logical replication actions have been performed as the
subscription owner, who will generally be a superuser. Commit
cec57b1a0fbcd3833086ba686897c5883e0a2afc documented hazards
associated with that situation, namely, that any user who owns a
table on the subscriber side could assume the privileges of the
subscription owner by attaching a trigger, expression index, or
some other kind of executable code to it. As a remedy, it suggested
not creating configurations where users who are not fully trusted
own tables on the subscriber.
Although that will work, it basically precludes using logical
replication in the way that people typically want to use it,
namely, to replicate a database from one node to another
without necessarily having any restrictions on which database
users can own tables. So, instead, change logical replication to
execute INSERT, UPDATE, DELETE, and TRUNCATE operations as the
table owner when they are replicated.
Since this involves switching the active user frequently within
a session that is authenticated as the subscription user, also
impose SECURITY_RESTRICTED_OPERATION restrictions on logical
replication code. As an exception, if the table owner can SET
ROLE to the subscription owner, these restrictions have no
security value, so don't impose them in that case.
Subscription owners are now required to have the ability to
SET ROLE to every role that owns a table that the subscription
is replicating. If they don't, replication will fail. Superusers,
who normally own subscriptions, satisfy this property by default.
Non-superusers users who own subscriptions will need to be
granted the roles that own relevant tables.
Patch by me, reviewed (but not necessarily in its entirety) by
Jelte Fennema, Jeff Davis, and Noah Misch.
Discussion: http://postgr.es/m/CA+TgmoaSCkg9ww9oppPqqs+9RVqCexYCE6Aq=UsYPfnOoDeFkw@mail.gmail.com
2023-04-04 17:25:23 +02:00
|
|
|
* made within it.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
RestoreUserContext(UserContext *context)
|
|
|
|
{
|
|
|
|
if (context->save_nestlevel != -1)
|
|
|
|
AtEOXact_GUC(false, context->save_nestlevel);
|
|
|
|
SetUserIdAndSecContext(context->save_userid, context->save_sec_context);
|
|
|
|
}
|