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 1vOVRw-00AP0W-2D for pgsql-general@arkaria.postgresql.org; Thu, 27 Nov 2025 06:25:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vOVRt-003pCi-2E for pgsql-general@arkaria.postgresql.org; Thu, 27 Nov 2025 06:25:50 +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 1vOVRt-003pCA-0m for pgsql-general@lists.postgresql.org; Thu, 27 Nov 2025 06:25:49 +0000 Received: from mail-lj1-x242.google.com ([2a00:1450:4864:20::242]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vOVRr-001jkP-0e for pgsql-general@lists.postgresql.org; Thu, 27 Nov 2025 06:25:49 +0000 Received: by mail-lj1-x242.google.com with SMTP id 38308e7fff4ca-37b999d0c81so4299661fa.2 for ; Wed, 26 Nov 2025 22:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764224746; x=1764829546; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:sender:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eQe87VVw1+KdDmRAjGzb1oW7shK8evFvONMnEX0CFis=; b=FQ6cytaCSpOBFThLj6YYA3RAx7sYmI67QRYIFXfVNfsyvoQctkyKnFYRnilVESJ0PH 8t+8S/+TgxwJ1TdfbzCHU+CPdfsOB4aa0IITBJkoAridrFN6ZoOJ/ULXQcTgoFvv05le cxy0YF1itsfo1NRR5PVFDiTOjDUcjswqff0Q8xVapfoCCzl6/Voc1QY7SucAdljO7Kni hMYOOkg8+tndFde9xzHEYJmdsafD9lm4G492EqOgc8zPYEekPlk1AKLzF6lVqT1p+OE1 uUMD8bm6UASLg/rgbQS0lsvlCjSBigRvamroOf8cHsaknxvfGQ3cswXeT7p+YNwbB0zR GORA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764224746; x=1764829546; h=cc:to:subject:message-id:date:from:x-google-sender-delegation :sender:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eQe87VVw1+KdDmRAjGzb1oW7shK8evFvONMnEX0CFis=; b=KnBVYVgplA4YE8c9vPstnJSE7JANUZ2jPJVxBtsNMXCS70SsnT5k2RFrIdflLROrXM s9dnnr6YcPN1QWHwKcK6Iusjmgtq1scy0SKuf4lAC/8jZKsnfjJnz/4+mn8ow/C+HVA+ lWUNy6f0QC+c+D87DadoEyWbq6cQTA71yNdcXt2Y5Bp/dCOczWO1wIJVH5dClUvaFZvy 090xXC19HKdIULl8A9HJ/Sn1bndkz5Stz955/EgiAGwXT5Cx5CF3l8l6t+OEt5KHADQ7 wWYJEtRWUT/THdOa1513dg7z/BhvdFfwTS/qIz0DBqwF1rlEwmV4P1yprSXDxFzsCmZp DFOw== X-Gm-Message-State: AOJu0YxaAK3hMZVJc814pA3iX98gwYpeA7uDOSRMl0IiskwyaKl1PSNi 3fVSwWKrQn3DtaYfEYNvmBRl1UCBa3bHe322VSdTKkHpJtaau5hFOU0aNidt44qX6VQUJE7jEk4 eKpOLBiBgNiDJoSnoccGo30blfPod3BU= X-Gm-Gg: ASbGncv5W3WflgDHsmB3ZkMs1oLJxVZxb4FtBmhXuHQp8euTfA4k5KdOvrvV84JszH2 SXa+jMBycH2cJkjC4r0LfWys3ZfyQc2xRJkLes8RfYeKVF6YZTgOhb1WauKYVFlAYmNJjTbuajq 4wtceDb/2hgRbln+SU3YwqO4olcCmC9eIgpckgth33BLsQrNkb9rcnVAr0FLnnQAEPd7N4sRpIe bilvQxXYV1EqH6wNihgilLWpdf2g2/dObhfrvAuklOKUEu4EsLJ+FI03YwbcQRxdztgWjE= X-Google-Smtp-Source: AGHT+IHTX64luSd5c2YwwOLoKKklHpaSHkISfeM4yOvBxNfjDPNASAU3JI/zpz1MFt/dCRUh1Iy3/ddeHMbMQV00BrM= X-Received: by 2002:a05:651c:43d8:20b0:37a:432f:8ecc with SMTP id 38308e7fff4ca-37d07953a3emr29536651fa.33.1764224745327; Wed, 26 Nov 2025 22:25:45 -0800 (PST) MIME-Version: 1.0 References: <176402341688.7.8547269556353940402.1025478372@georgiou.vip> In-Reply-To: <176402341688.7.8547269556353940402.1025478372@georgiou.vip> Sender: calvinguo@gmail.com X-Google-Sender-Delegation: calvinguo@gmail.com From: Calvin Guo Date: Thu, 27 Nov 2025 14:25:33 +0800 X-Google-Sender-Auth: TCBCaLPu7kvbqPJ-Gbz09KeBDB0 X-Gm-Features: AWmQ_bmrWnvEuOBxTFyBxqxq7_UdSyJBWZ1NqxdJP78KTXInwSwGIxbgYDZlYOQ Message-ID: Subject: Re: set role command To: pg254kl@georgiou.vip Cc: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="0000000000003fcec506448d9583" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003fcec506448d9583 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable create role usera_sandbox in group usera; \c - usera_sandbox but what will happen if I then issue: reset role? I don't think it is a real sandbox. You can always escape. To make it worse, I tested "set session authorization rolename", which will change the session user and current user to new rolename. But I can still do reset session authorization to go back to super user. Seems like once I connect as a super user, there is no way for drop the previledge. On Tue, Nov 25, 2025 at 6:30=E2=80=AFAM wrote: > 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! > > --0000000000003fcec506448d9583 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
crea= te role usera_sandbox in group usera;
= \c - usera_sandbox
but what will happen if I then issue:
reset role?
I don't think it is = a real sandbox. You can always escape.

To make it worse, I tested "set se= ssion authorization rolename", which will change the session user and = current user to new rolename. But I can still do=C2=A0
reset session authorizat= ion
to go back to = super user.

Seems like once I connect as a super user, there is no way for dro= p the previledge.

On Tue, Nov 25, 2025 at= 6:30=E2=80=AFAM <pg254kl@georgiou.vip> wrote:
=20 =20 =20

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 i= n group usera;
\c - usera_sandbox

=C2=A0=C2=A0

--=20
regards,
Kiriakos Georgiou


On 11/24/25 3:15 AM, Calvin Guo - newoakllc2023 at gmail= .com wrote:
=20
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=C2=A0
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!

  
--0000000000003fcec506448d9583--