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 1vNRjC-002p7x-37 for pgsql-general@arkaria.postgresql.org; Mon, 24 Nov 2025 08:15:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vNRjB-00HByq-1a for pgsql-general@arkaria.postgresql.org; Mon, 24 Nov 2025 08:15:17 +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 1vNRjB-00HByh-0H for pgsql-general@lists.postgresql.org; Mon, 24 Nov 2025 08:15:17 +0000 Received: from mail-lj1-x243.google.com ([2a00:1450:4864:20::243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vNRj9-001C1T-0j for pgsql-general@lists.postgresql.org; Mon, 24 Nov 2025 08:15:16 +0000 Received: by mail-lj1-x243.google.com with SMTP id 38308e7fff4ca-37b996f6b28so33374731fa.3 for ; Mon, 24 Nov 2025 00:15:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763972114; x=1764576914; darn=lists.postgresql.org; h=to:subject:message-id:date:from:sender:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=EEN+ixH8b52AE2IGzcWkJsuVhD6VvjsxfvO+WsQUYD8=; b=S60kLIbkDD+YVG23mWTYqzXEiO902eM2gs97Gb1rlH0nIKUqfkZYwNad7i2JyiEHU5 Jly/X2gcun+I8LZYKQipvBOVn7tOhzk5Weh0Y7VE1HFH4h0r1PfYYFO50pBkU0ywtgLH moSn/sz9pqVrPaWirxlq3g8QWK52xkZ2JABOqA+H4XcZRR1SB6sh/6W8xvxtH0/i2KnF jX9fE5EdtRUX8UANiqxZ/V2em0pKpvNuX1HPwS5vXiybeSkY7Irz0/7idTwQYgb6E68T Lvm3NbG0ySufgjfSOp6EAokLS6WYTOsNgAKuv5f96A3gMS5T25LbDZtj8lLNaikDY4Tc 5Mag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763972114; x=1764576914; h=to:subject:message-id:date:from:x-google-sender-delegation:sender :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=EEN+ixH8b52AE2IGzcWkJsuVhD6VvjsxfvO+WsQUYD8=; b=Yet3fXgn15co66NLHF7Ypoxz99M9oF7AU6mRTlocQJQtRHvGUoo7vffYpQB4/qCOSi Unx7sLMdkvWYepA5rLfeaf4D42zDPlgMRZW8ilJTj4T/L7syqI82b+/3nNyrvChXtkRE 4Npv0gIxWgJpP+XUf6epAO2tXtvNb66mbzyOaGDhelokFn0XqvpV0HoGsCM2n0a5ZDbq wLLza4gsn00Q5o12bWsWCN5Uu7A3G8s+0nppm4ENmrfqqLnIXdymm8xzNDVekcwStaYK yYepFLJoZFff93em+b6REj7IoEDE7Nwzr93Foep301BaEdL3Je9Ae04A5XptGgc0nMyy L5SQ== X-Gm-Message-State: AOJu0YzvgN/6tD3JykDnOjvsuUV9gCFj+eCFifJ0ac5J3sRVMxgIkC85 MbPf52j7mqV4qJDjIqkSIkMvmrr6Gipdx2aghmbwM5cvYEUfFGAMJMeLoL9FNkVzEywWghWK5qX xSItTy1Rt/eFAN3YvMnMaeoEEnq+wVQMEhmUWPu0= X-Gm-Gg: ASbGnct3OZX/AWFxsS52jgv3+OAhihn0XxKt9xxjTXk3Kl0+BbgoWHygkhfIXETaRRk qDllR5Nzx63uCmSDbPyFhBRAPdo1QoeqSIg+04MO8r8TrV4FxVLzbOYK5CU7EPM5LfVsM3+fqy6 sQLtjNagMtDTFXoxCkBZ32VgopU6Jv9/SeZH3ycLaSJdSONa3BKFAaVKXDbEMgL5ujA59KOfdOW 2fprsDmzoUDoRRQJRVFQpyDfsMlOvPnakWxgKbnU4erJndX5TavWFTvfanoVIZKhrsmAHCSvYzp GvCb3w== X-Google-Smtp-Source: AGHT+IF9mBs9VYIJBfvK4Mo2ofDmO8RYkJIhazJa8ltRcptjSkZZuLBZFhAlLr7GaTQ37UcZ9+rGAy3meQKKpWxXcHE= X-Received: by 2002:a2e:800f:0:b0:336:df0e:f4ac with SMTP id 38308e7fff4ca-37cd9239c41mr23660021fa.25.1763972113363; Mon, 24 Nov 2025 00:15:13 -0800 (PST) MIME-Version: 1.0 Sender: calvinguo@gmail.com X-Google-Sender-Delegation: calvinguo@gmail.com From: Calvin Guo Date: Mon, 24 Nov 2025 16:15:03 +0800 X-Google-Sender-Auth: ub5HIWyjmZKR0HqqgrRJf29r30c X-Gm-Features: AWmQ_bl2FJKf8J62uHajjIKZLlnr2K2Oloc7ow7JdWeGaRL9Lkuopa5obTTrVEY Message-ID: Subject: set role command To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000035f7db064452c3be" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000035f7db064452c3be Content-Type: text/plain; charset="UTF-8" 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! --00000000000035f7db064452c3be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I feel that set role logic is kindof misleading.

<= /div>
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 u= serb; other sql,
or=C2=A0
reset role; orther sql,
=
it turns out it's not safe at all, the sql can easily get access r= ight 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 ha= ve 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!
--00000000000035f7db064452c3be--