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 1jWw6n-0001bC-CX for pgsql-docs@arkaria.postgresql.org; Fri, 08 May 2020 06:03:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jWw6m-0000p5-9m for pgsql-docs@arkaria.postgresql.org; Fri, 08 May 2020 06:03:40 +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 1jWw6m-0000ov-16; Fri, 08 May 2020 06:03:40 +0000 Received: from mail-pg1-x543.google.com ([2607:f8b0:4864:20::543]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jWw6e-0002ql-V1; Fri, 08 May 2020 06:03:39 +0000 Received: by mail-pg1-x543.google.com with SMTP id l25so388431pgc.5; Thu, 07 May 2020 23:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=kopLGDex2InMJKfUQRy+x5W7/EnvkuInBRF5dI6JNBo=; b=EF9hoEksVxBs2a9uEyT8qkNOqsZgxR/a13kLOoJEJSruzZPLLLQTnSiG9j3MGCMf1g G1a8nIn2ktid7BwZgZ3FQhtRjGw9RaaCQ+35rHsxLemZfaSHCgMSBtf0FMZPjVe5sE1/ y4eil3zVnAB12xOZovl49Lv56ljBvbAYEPRnovaEEbds1Q69Rjwk8H5succEeYRvjR8W y++kFWYm9HFz5f2C4MlQevPlBfiwBDC4aRab4pWWxRvgKNSg/v0T6suH2dY20WbdTymj 0Bw9mrneGneOl0vkVLhFRIN2lKjjaMTvaJuK+w27yy3tOnPZVWehTVRiRpGv6/42KhFn jzLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=kopLGDex2InMJKfUQRy+x5W7/EnvkuInBRF5dI6JNBo=; b=N6xUyRMGaJeENpStTagjP3MV8BXEaz3heBmTnewpzoEmeNxCJNVUrx2pSwj96tYqJQ qDs/ADceDeJJ1csd7IeDcdkWRvZX805GLM0Mu99dNrZyUn6nKww7AMamJV8WYF+Ydysa OS2yfmBONTMcpKmWi66zRvmxTazBbJ5tUCskcu//QLQgFnRe+mYs+5ox3tfrKUqKeXQd p/dwF+sRUHM2xj8ck0tiV1BdDoG7H6G5lsNBwvwRYHLyokFjuimnxkjwsVYjN4pf+cQI zcWuIoz2HFWbCAh6E50Bs7lyoU6f7UHVrVv7QBEGm2WT44eguY1wbCQmPMeTTNqnN1Eq 5G4A== X-Gm-Message-State: AGi0PuZErhviJrUl72cOjeo1Q7f2DBKAnc4SOnwyHey/qgfvwy6gM7fs xrsuh5IVWqlmFDVe+A14PbQ= X-Google-Smtp-Source: APiQypJ/+3TEvf3WxwY8HPSxLFX4Zx2yrtJnhoVCMPYWYklPMgyKpsRkRyFkoziXapRtv5Ra6HBbUg== X-Received: by 2002:a62:844c:: with SMTP id k73mr1105535pfd.235.1588917810658; Thu, 07 May 2020 23:03:30 -0700 (PDT) Received: from localhost (ag027197.dynamic.ppp.asahi-net.or.jp. [157.107.27.197]) by smtp.gmail.com with ESMTPSA id c1sm628925pfo.152.2020.05.07.23.03.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2020 23:03:30 -0700 (PDT) Date: Fri, 08 May 2020 15:03:26 +0900 (JST) Message-Id: <20200508.150326.909507514141434296.horikyota.ntt@gmail.com> To: alvherre@2ndquadrant.com Cc: tgl@sss.pgh.pa.us, sfrost@snowman.net, chris+postgresql@qwirx.com, pgsql-docs@lists.postgresql.org, pgsql-hackers@lists.postgresql.org, peter.eisentraut@2ndquadrant.com Subject: Re: Logical replication subscription owner From: Kyotaro Horiguchi In-Reply-To: <20200508050211.GA6945@alvherre.pgsql> References: <17709.1588908623@sss.pgh.pa.us> <20200508050211.GA6945@alvherre.pgsql> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk At Fri, 8 May 2020 01:02:11 -0400, Alvaro Herrera wrote in > On 2020-May-07, Tom Lane wrote: > > > FWIW, I would argue that LOGIN permits logging in on a regular SQL > > connection, while REPLICATION should permit logging in on a > > replication connection, and there's no reason for either to depend on > > or require the other. > > I agree with this. I agree, too. Anyway, it is unreasonable that a user is banned for the lack of replication-attribute after a successful *replication* login. LOG: replication connection authorized: user=user1 application_name=psql FATAL: must be superuser or replication role to start walsender > > >> Also- what about per-database connections? Does having REPLICATION mean > > >> you get to override the CONNECT privileges on a database, if you're > > >> connecting for the purposes of doing logical replication? > > > > No, why would it? Should LOGIN privilege mean you can override > > CONNECT? That's nonsense. You need the respective privilege > > to connect with the protocol you want to connect with, and you > > also need CONNECT on the DB you want to connect to. > > And this. A user can start physical replication without needing CONNECT on any database if it has REPLICATION attribute. That means any user that is allowed logical replication on a specific database (or even no databases) can replicate the whole cluster using physical replication. I don't think it is a proper behavior from the security perspective. It seems to me that we need to restrict physical replication to require CONNECT privilege on all databases, or separate physical replication privilege from logical replication privilege. regards. -- Kyotaro Horiguchi NTT Open Source Software Center