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 1mnOoQ-0004tt-Ip for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Nov 2021 17:33:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mnOoO-0003a7-Vf for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Nov 2021 17:33:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mnOoO-0003Ym-J7 for pgsql-hackers@lists.postgresql.org; Wed, 17 Nov 2021 17:33:32 +0000 Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mnOoL-0001kD-6j for pgsql-hackers@postgresql.org; Wed, 17 Nov 2021 17:33:31 +0000 Received: by mail-pl1-x62e.google.com with SMTP id v19so2784469plo.7 for ; Wed, 17 Nov 2021 09:33:28 -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=VzYpnwQmva6kS73Udm8UTF94/m1pt2wzqnfhvxSVu4k=; b=5rFU/lrdFB2YwYYsayWHP5FuHTu9flb/XyGyuaP6iBEeaBaqy8YyJyrmdmjDYL+mdV S1keuVh3X2ceUZhh0aiwAzwdy6maXvw9fAG+0YoU9CkjbzeeDCbMTO5AvztYmvfUENuT FxX/YbPP8DO114VDXpkkM+rZjnP7SKCXszaZf2X4w7MEbfX7ae8rdGCUEtQN2C/Q/XhE P0G7kzEy7LF2MasbtHdJvfVGrmIADsSqtjWWYXUZUFKc+AvcesFW4S2V3Nb2RqIlI6SU lhJ5P3/oT8upuvrvstg8Y9Fn8xYGh1sSvk79qT0AJZxitBx/wxREseDL8Vu5iUvehUOq wx0Q== 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=VzYpnwQmva6kS73Udm8UTF94/m1pt2wzqnfhvxSVu4k=; b=Npljw3Znh6ROaDWBNuGvXraKxHH7Sco+Q/PRIo5NIdp0sl1FQmqicFYEC/YPsjiEZb tnF9jyau3Xul8/hKG/HCHTLsxWshuaPoETtUaIqqEBFwAADOBLIzSql//L2oe2Dg5cFy kQR1ovFSm2Nb8eHGb9tE78uF7ghuraaGdyMdzUqciDh8csd2NumecuPmq1Qk7dePJ9d8 H1Q4d3C3xeTe8Ngo/Pe26LKeKeh2piEwk3oQwO3HkRv9+TVBsr1YDklQhNxqp64DPtmW A6M5U2idLBhwIFbCpGYdkRUQSJtxhOi6gjLNtVNW5QyYi6g36TauDOZi5+5LxzTKGdbr 5TJA== X-Gm-Message-State: AOAM533eoRx7tynAEwzOnzwbu4zO1IzWAs+9JStD+fKf8105reHmgVRX E/AyLSbSPzCJRUuPkbE8oMN6oQ== X-Google-Smtp-Source: ABdhPJyA722EQPNro5fVwyQwVWnDqwR0K6BZz2ecS7kCMu++X97K9+wSR1+uWQycRThZ2BC4FF2+BA== X-Received: by 2002:a17:90b:fd5:: with SMTP id gd21mr1706628pjb.37.1637170406935; Wed, 17 Nov 2021 09:33:26 -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 p15sm251821pjh.1.2021.11.17.09.33.25 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Nov 2021 09:33:26 -0800 (PST) Message-ID: Subject: Re: Non-superuser subscription owners From: Jeff Davis To: Mark Dilger Cc: Andrew Dunstan , PostgreSQL-development , Robert Haas Date: Wed, 17 Nov 2021 09:33:24 -0800 In-Reply-To: <6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.com> References: <9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com> <6BB4451E-7B1B-474C-BD1F-DB7531E720C6@enterprisedb.com> <6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.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 Wed, 2021-11-17 at 07:44 -0800, Mark Dilger wrote: > Administrators may quite > intentionally create low-power users, ones without access to anything > but a single table, or a single schema, as a means of restricting the > damage that a subscription might do (or more precisely, what the > publisher might do via the subscription.) It would be surprising if > that low-power user was then able to recreate the subscription into > something different. I am still trying to understand this use case. It doesn't feel like "ownership" to me, it feels more like some kind of delegation. Is GRANT a better fit here? That would allow more than one user to REFRESH, or ENABLE/DISABLE the same subscription. It wouldn't allow RENAME, but I don't see why we'd separate privileges for CREATE/DROP/RENAME anyway. This would not address the weirdness of the existing code where a superuser loses their superuser privileges but still owns a subscription. But perhaps we can solve that a different way, like just performing a check when someone loses their superuser privileges that they don't own any subscriptions. Regards, Jeff Davis