Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vNf4g-00AClJ-3B for pgsql-general@arkaria.postgresql.org; Mon, 24 Nov 2025 22:30:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vNf4e-0057I0-2f for pgsql-general@arkaria.postgresql.org; Mon, 24 Nov 2025 22:30:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vNf4e-0057Hs-1Q for pgsql-general@lists.postgresql.org; Mon, 24 Nov 2025 22:30:20 +0000 Received: from mail-200165.simplelogin.co ([176.119.200.165]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vNf4c-001JDA-2V for pgsql-general@lists.postgresql.org; Mon, 24 Nov 2025 22:30:20 +0000 ARC-Seal: i=1; a=rsa-sha256; d=simplelogin.co; s=arc-20230626; t=1764023417; cv=none; b=u27TVi38LIOWCiZj6s7rzcgyMG66GbNa9UhwQvRiOIDczr8yUs6tGgnmDJD8ThocsT1BI8diLBhsB6ZO1VLxhDW8uSVKwcEHlWNb6VbI2BCPoIPuTtvK94WiYYv7PqEB9bjCq6VT/w3Denp6BXEhw2Orb2iY/IRPPUGa/4u5owS2G4EaMMLiFt2wfJtYEHHwHYLwJQyDViqXBgRwjko3Srrns7Kzw808UWgMAdtKU/VyHmvdGWyznXY/PIsyMYoS56s9eHHEMOuAkYpn/zR2APWNQSvF28DVglRqrMQyDG6FHbv4/lp5V7ZJzRL1UOAxONICqlwb4Y9fMvX3RkzM7A== ARC-Message-Signature: i=1; a=rsa-sha256; d=simplelogin.co; s=arc-20230626; t=1764023417; c=relaxed/simple; bh=yE93Y+UwrM6Io+SrNr9JVco/TtQeeyzew07PglY6Mn8=; h=Date:Subject:In-Reply-To:From:To:References; b=tZqtMgfRKxQhPtsB/aQuU/dOipOSIx318S+q4CE8qszK4GTTxJpPE2Q15Kv5TKxaJjBee4/QQtuqmOC2OxuU58oAE2j8q7ymqO+hM+ugScCg7z7a9YQphvv8X/CuQi4G8YAVAmVQXH5LIBHnWKdCFCRt6g84ejQzexJvmFNpD8y5BKsKFslIxvp63Gq12M2qMYSxg9iA1ZV7WnVOOsPMBga9KD0e0f016mndQiML1MVbmeRm4T75XDVYx3/xLBl1cTxLbhTyDgsc/GB3hexd9EIgT/KcpyntkCTvXdGBvh5CSxOlTQW2V4bCIlu+QnEcPf5We2BldxXUuaKMJnjagw== ARC-Authentication-Results: i=1; mail.protonmail.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=georgiou.vip; s=dkim; t=1764023417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PRPspTFhc2Q41VuciAsAxUd74IzrOuGxIyONFaEFoKA=; b=kBjYsDdzgZd+R9kpiLquW9KLSfXtmB6us+NCiKioWAId0LsGjgkUOdfS8anMnWPGxNUnj3 P7FoQNC9HMZajmlXdqsXMk/fd9YTLUhUh5tCMkumOSxLulFWku6wtijqgON5mYXKSXtrbm zk8Qw1OElVQIqNUgTxEgyF9BILkIcxg= Content-Type: multipart/alternative; boundary="------------rnMi669CUgeyG0BBY504IBC0" Date: Mon, 24 Nov 2025 17:30:14 -0500 MIME-Version: 1.0 Subject: Re: set role command In-Reply-To: Content-Transfer-Encoding: 7bit From: pg254kl@georgiou.vip To: Calvin Guo ,"pgsql-generallists.postgresql.org" Message-ID: <176402341688.7.8547269556353940402.1025478372@georgiou.vip> References: X-SimpleLogin-Type: Reply X-SimpleLogin-EmailLog-ID: 1025478374 X-SimpleLogin-Want-Signing: yes List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------rnMi669CUgeyG0BBY504IBC0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Just because you did set role does not mean you lost your superuser privileges, it's correct behavior. If you want to impersonate in a permissions sandbox it's easy: create role usera_sandbox in group usera; \c - usera_sandbox -- regards, Kiriakos Georgiou On 11/24/25 3:15 AM, Calvin Guo - newoakllc2023 at gmail.com wrote: > I feel that set role logic is kindof misleading. > > I am a superuser, admin, > I do: > set role usera > Now I am under the security context of usera, so I think running any > sql is safe as long as it's allowed by usera. > > Which is not the case! > as usera can do: > set role userb; other sql, > or > reset role; orther sql, > it turns out it's not safe at all, the sql can easily get access right > of the super user. it can impernate userb though they do not have any > relationship whatso ever. > > I really feel, once you "set role usera", you should behave like > usera, you should NOT have the power say: hi, I can assume my super > user power whenever I want. As this make the "set role usera" pretty > much useless. > > It's unsafe! --------------rnMi669CUgeyG0BBY504IBC0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Just because you did set role does not mean you lost your superuser privileges, it's correct behavior.

If you want to impersonate in a permissions sandbox it's easy:

create role usera_sandbox in group usera;
\c - usera_sandbox

  

-- 
regards,
Kiriakos Georgiou


On 11/24/25 3:15 AM, Calvin Guo - newoakllc2023 at gmail.com wrote:
I feel that set role logic is kindof misleading.

I am a superuser, admin,
I do:
set role usera
Now I am under the security context of usera, so I think running any sql is safe as long as it's allowed by usera.

Which is not the case!
as usera can do:
set role userb; other sql,
or 
reset role; orther sql,
it turns out it's not safe at all, the sql can easily get access right of the super user. it can impernate userb though they do not have any relationship whatso ever.

I really feel, once you "set role usera", you should behave like usera, you should NOT have the power say: hi, I can assume my super user power whenever I want. As this make the "set role usera" pretty much useless.

It's unsafe!

  


--------------rnMi669CUgeyG0BBY504IBC0--