Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ms9xE-0001Y9-Lp for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Nov 2021 20:42:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ms9xD-0006xk-Ii for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Nov 2021 20:42:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ms9xD-0006xb-6g for pgsql-hackers@lists.postgresql.org; Tue, 30 Nov 2021 20:42:19 +0000 Received: from mail-pf1-x431.google.com ([2607:f8b0:4864:20::431]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ms9xA-0001wQ-Py for pgsql-hackers@postgresql.org; Tue, 30 Nov 2021 20:42:18 +0000 Received: by mail-pf1-x431.google.com with SMTP id z6so21824401pfe.7 for ; Tue, 30 Nov 2021 12:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=rqsU+HI+pej8+G4i3VisNYZrn2y1hMmxDGVfDToRU4w=; b=EKq9a62EnPMx4rfSWDD9TOtHQ6QZHpAEzl04rpxeJwUKyKnYBlAjoZRZs0yQoJ4grK 0xfxd68AFvAEeVIl/CTyNX5Mt9QJg/al8xNUT4seCLvVQALZU3Yy7mXq93ti2kIYDMX7 RzhtXSksTtdI6e4zLZMqrl5BVETDxX/9rdxgiPvH7QHbOHNIIXL9LItUz5SUBjjPwOoa wYVL7cv6uwIQzAhNPiqAzjaJ0iTyPyv1MARSyYs5eg/KeJXe0GQneKM/PM2M0W4KPKGT CsIgJTkGP4Z9i1qne/pb9XSj4mEW6Gvd+WMyVW+yZ1vLU7nMPkAjo1c6FcdpfenSm6Ul pXRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=rqsU+HI+pej8+G4i3VisNYZrn2y1hMmxDGVfDToRU4w=; b=YcELmiHAN22R3RcogBEmm4UgWMcJVk4h3JBYe0LygzFkjteOzLBrLgKC/KkEFgzuT3 AXKlVAZs7WOf8Y76lC5MdVm88JHtZxSr9Kl6zJqWnbvKQM03GNILJb7NRGsP+BAvi+GP OfbGsDzIxMWo5L72vRw15Z28yeHjYe2Z4rSvto31sNnL7bx3KrbVkTk2wo+05ZC56XQP W2XeqL9C3314eDI9ddUxolUF8pm5SbYTtkep5ZCRXMZWjZurRlEAaoVqLOvIRjBFCvcy ecCncDf9M1u+kPg5NUHOHj5BmsEHEUmsEDltyHDh9QyEEb9M31rvaOgfys7cBBGVuCi7 mXuA== X-Gm-Message-State: AOAM531KgT0seehb1gnZdkvNP6AYVA2LsMjs7c95VCHP67pWiZ/gVQb6 gXi/m3QMr2cBmYlkQ9ch6Io+HA== X-Google-Smtp-Source: ABdhPJwUyEoxsSVBlxZnkkgxAW5rgQuv5mAL8M8U5rp7GL0U+klpPH2OVfVegQCqp3hSY3edqwZwHw== X-Received: by 2002:a63:bf45:: with SMTP id i5mr1250822pgo.161.1638304935829; Tue, 30 Nov 2021 12:42:15 -0800 (PST) Received: from jdavis.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id i67sm21497116pfg.189.2021.11.30.12.42.14 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 30 Nov 2021 12:42:14 -0800 (PST) Message-ID: Subject: Re: Non-superuser subscription owners From: Jeff Davis To: Amit Kapila Cc: Mark Dilger , Andrew Dunstan , PostgreSQL-development , Robert Haas Date: Tue, 30 Nov 2021 12:42:13 -0800 In-Reply-To: References: <9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com> <6BB4451E-7B1B-474C-BD1F-DB7531E720C6@enterprisedb.com> <6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.com> <1BB0A553-3FE9-4A91-A975-6F9D8C157FBD@enterprisedb.com> <7C62876F-5D19-4B5C-96AC-5590B10A49B2@enterprisedb.com> <66f55a6b9ff7bdd6bfd0d05e8fd8351690e69e23.camel@j-davis.com> <18b267939a9d1ae27e9b3643d53395f4e29ea6ce.camel@j-davis.com> <785e8b8ab06f123cf754862557bd3171aeba4d65.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 2021-11-30 at 17:25 +0530, Amit Kapila wrote: > I think it would be better to do it before we allow subscription > owners to be non-superusers. There are a couple other things to consider before allowing non- superusers to create subscriptions anyway. For instance, a non- superuser shouldn't be able to use a connection string that reads the certificate file from the server unless they also have pg_read_server_files privs. > Yeah, it is possible that is why I suggested in one of the emails > above to allow changing the owners only for disabled subscriptions. The current patch detects the following cases at the transaction boundary: * ALTER SUBSCRIPTION ... OWNER TO ... * ALTER ROLE ... NOSUPERUSER * privileges revoked one way or another (aside from the RLS/WCO problems, which will be fixed) If we want to detect at row boundaries we need to capture all of those cases too, or else we're being inconsistent. The latter two cannot be tied to whether the subscription is disabled or not, so I don't think that's a complete solution. How about (as a separate patch) we just do maybe_reread_subscription() every K operations within a transaction? That would speed up permissions errors if a revoke happens. Regards, Jeff Davis