On Wed, Jul 12, 2023 at 09:37:57PM -0700, Nathan Bossart wrote:
> On Mon, Jul 10, 2023 at 01:49:55PM -0700, Nathan Bossart wrote:
>> Great. I'm going to wait a few more days in case anyone has additional
>> feedback, but otherwise I intend to commit this shortly.
>
> I've committed 0001 for now.
On Mon, Jul 10, 2023 at 01:49:55PM -0700, Nathan Bossart wrote:
> Great. I'm going to wait a few more days in case anyone has additional
> feedback, but otherwise I intend to commit this shortly.
I've committed 0001 for now. I'm hoping to commit the other two patches
within the next couple of da
On Mon, Jul 10, 2023 at 04:46:07PM -0400, Joseph Koshakow wrote:
> Thanks, I think the patch set looks good to go!
Great. I'm going to wait a few more days in case anyone has additional
feedback, but otherwise I intend to commit this shortly.
--
Nathan Bossart
Amazon Web Services: https://aws.a
On Mon, Jul 10, 2023 at 4:32 PM Nathan Bossart
wrote:
> Okay. Here's a new patch set in which I believe I've addressed all
> feedback. I didn't keep the GetAuthenticatedUserIsSuperuser() helper
> function around, as I didn't see a strong need for it.
Thanks, I think the patch set looks good to
On Sun, Jul 09, 2023 at 08:54:30PM -0400, Joseph Koshakow wrote:
> I just realized that you moved this comment from
> SetSessionAuthorization. I think we should leave the part about setting
> the GUC variable is_superuser on top of SetSessionAuthorization since
> that's where we actually set the GU
On Sun, Jul 9, 2023 at 1:03 PM Joseph Koshakow wrote:
>> * Only a superuser may set auth ID to something other than himself
> Is "auth ID" the right term here? Maybe something like "Only a
> superuser may set their session authorization/ID to something other
> than their authenticated ID."
>>
On Sun, Jul 9, 2023 at 12:47 AM Nathan Bossart
wrote:
> I think we should split this into two patches: one to move the permission
> check to check_session_authorization() and another for the behavior
change.
> I've attached an attempt at the first one (that borrows heavily from your
> latest patc
On Sat, Jul 08, 2023 at 07:08:35PM -0400, Joseph Koshakow wrote:
> On Sat, Jul 8, 2023 at 6:09 PM Nathan Bossart
> wrote:
>
>>> I think the issue here is that if a session loses the ability to set
>>> their session authorization in the middle of a transaction, then
>>> rolling back the transactio
On Sat, Jul 8, 2023 at 6:09 PM Nathan Bossart
wrote:
>> I think the issue here is that if a session loses the ability to set
>> their session authorization in the middle of a transaction, then
>> rolling back the transaction may fail and cause the server to panic.
>> That's probably what the dele
On Sat, Jul 08, 2023 at 04:44:06PM -0400, Joseph Koshakow wrote:
> 2023-07-08 16:33:27.787 EDT [157141] PANIC: ERRORDATA_STACK_SIZE exceeded
> 2023-07-08 16:33:27.882 EDT [156878] LOG: server process (PID 157141) was
> terminated by signal 6: Aborted
> 2023-07-08 16:33:27.882 EDT [156878] DETAIL:
I've discovered an issue with this approach. Let's say you have some
session open that is connected as a superuser and you run the following
commands:
- CREATE ROLE r1 LOGIN SUPERUSER;
- CREATE ROLE r2;
- CREATE ROLE r3;
Then you open another session connected with user r1 and run the
follo
Nathan Bossart wrote:
> I see that RESET SESSION AUTHORIZATION
> with a concurrently dropped role will FATAL with your patch but succeed
> without it, which could be part of the reason.
I didn't even realize it, but the change to superuser_arg() in v2 fixed
this issue. The catalog lookup is only
>> That might be a good change? If the original authenticated role ID no
>> longer exists then we may want to return an error when trying to set
>> your session authorization to that role.
>
> I was curious why we don't block DROP ROLE if there are active sessions
for
> the role or terminate any su
On Thu, Jun 22, 2023 at 06:39:45PM -0400, Joseph Koshakow wrote:
> On Wed, Jun 21, 2023 at 11:48 PM Nathan Bossart
> wrote:
>> I see that RESET SESSION AUTHORIZATION
>> with a concurrently dropped role will FATAL with your patch but succeed
>> without it, which could be part of the reason.
>
> Th
Hi,
I’ve just stumbled upon this patch and thread and thought I could share an idea
of adding an optional temporary secret to SET SESSION AUTHORIZATION so that it
is only possible to RESET SESSION AUTHORIZATION by providing the same secret
,like:
SET SESSION AUTHORIZATION [role] GUARDED BY ‘[s
On Wed, Jun 21, 2023 at 11:48 PM Nathan Bossart
wrote:
>
>On Wed, Jun 21, 2023 at 04:28:43PM -0400, Joseph Koshakow wrote:
>> + roleTup = SearchSysCache1(AUTHOID,
ObjectIdGetDatum(AuthenticatedUserId));
>> + if (!HeapTupleIsValid(roleTup))
>> + ereport(FATAL,
>
On Wed, Jun 21, 2023 at 04:28:43PM -0400, Joseph Koshakow wrote:
> + roleTup = SearchSysCache1(AUTHOID,
> ObjectIdGetDatum(AuthenticatedUserId));
> + if (!HeapTupleIsValid(roleTup))
> + ereport(FATAL,
> +
> (errcode(ERRCODE_INVALID_AUTHORIZATION_SPE
On Wed, Jun 21, 2023 at 04:28:43PM -0400, Joseph Koshakow wrote:
> Currently, a user is allowed to execute SET SESSION AUTHORIZATION [1]
> if the role they connected to PostgreSQL with was a superuser at the
> time of connection. Even if the role is later altered to no longer be a
> superuser, the
Hi all,
I briefly mentioned this issue in another mailing thread [0].
Currently, a user is allowed to execute SET SESSION AUTHORIZATION [1]
if the role they connected to PostgreSQL with was a superuser at the
time of connection. Even if the role is later altered to no longer be a
superuser, the s
19 matches
Mail list logo
