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.94.2) (envelope-from ) id 1sRXvs-00GK7v-3y for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jul 2024 14:04:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sRXvq-005UP2-OP for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jul 2024 14:04:30 +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.94.2) (envelope-from ) id 1sRXvq-005UOu-Es for pgsql-hackers@lists.postgresql.org; Wed, 10 Jul 2024 14:04:30 +0000 Received: from mail-il1-x12f.google.com ([2607:f8b0:4864:20::12f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sRXvo-001Os3-8j for pgsql-hackers@lists.postgresql.org; Wed, 10 Jul 2024 14:04:29 +0000 Received: by mail-il1-x12f.google.com with SMTP id e9e14a558f8ab-37636c3872bso25565545ab.3 for ; Wed, 10 Jul 2024 07:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720620266; x=1721225066; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IXftEx12Oo1OOej1IYKhjk4IdYEV5KaWQEgBqR5dKtQ=; b=D78qGXF2KIRYb7VVQf1rm7uAwiEDeULOTWd1pHmmPNvbpsgY0ClWE9Toejh/a90xKl jT0ulFGRnRLQrIUnplb5A05HmNRpxuoQzzZpu0XuZPgASMsFG2fIWKFLPC7TzwJ//pTu FyAYEEZhKKEIrE+WRtl32B4kDMZi+NEfH0x9SOQzcN2gKIKV6l6i3A4wSjlWNYdB1v18 oQaLT0BElKX9SoLaoTNIFLkmzVZT0ZRiT5a/JBLzqUprz3ODs+eINgUzpcKAgqsEv3p6 2Z2Edi1vlorKcsSySrrwf+Ep84/zw79ALqRw0iiVSJUYiApKEdQvyjHkVcjDw9vM+Rt3 EFCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720620266; x=1721225066; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IXftEx12Oo1OOej1IYKhjk4IdYEV5KaWQEgBqR5dKtQ=; b=iN8A/gj+rvBkhH2yMHhzdRuFtcX8fceBzCbTA2rH1cw+UPv74/GE5LWjsoO0Phfvbo i58jCYaLoovih4HrUY7+dfn+sepNP9QPH39VnRgtGVdi4gbM0QMRDmyZkb5DY0pN+kSq 0RYssci7Sj7X3LGwsuCAgTv8Qye0m5GgKrg/jAOw2pTg5d4V3UpBXYkkjCFb2BGXqnbe 8jwpxLFAxCwJagyUp/HE/9+bXAkBHsjneuZ3n2KTpeTPNpHngaboBB9By+ZLFY6x0niG VsuLpp3BM8GLJcPeTWkSe9j3739/0PCYpmI0LjljhZwk/zOXoD+2PYiExo9np9fp8Y6J QfJw== X-Gm-Message-State: AOJu0Yxs742GcdgQdZX3AiphJLMCJ5vaI78FzxpnewMm2/ApLZGavyM+ zQC93oTkMOS63qRBju7XjSR1VNaeweyrCyAn9bVFmPqNQrshE+QccLWNu6iw X-Google-Smtp-Source: AGHT+IE1VvDJ5IqA8CpevjXLnsaFYyvJTmT1tDeL4x+kJJzNjA+EFz7bGmI04Kw7uPhjfYZs+4C9WA== X-Received: by 2002:a92:c548:0:b0:374:5a2d:178 with SMTP id e9e14a558f8ab-38a56d0c2a9mr62938955ab.2.1720620266352; Wed, 10 Jul 2024 07:04:26 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4c0b1b5c6f1sm1142704173.79.2024.07.10.07.04.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jul 2024 07:04:25 -0700 (PDT) Date: Wed, 10 Jul 2024 09:04:24 -0500 From: Nathan Bossart To: Fujii Masao Cc: PostgreSQL Developers Subject: Re: pg_maintain and USAGE privilege on schema Message-ID: References: <56596b81-088f-4c0c-9a88-b5f27a7a62e9@oss.nttdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jul 10, 2024 at 05:13:58PM +0900, Fujii Masao wrote: > However, unlike the database owner, pg_maintain by definition should > have *all* the rights needed for maintenance tasks, including MAINTAIN > rights on tables and USAGE rights on schemas? ISTM that both > pg_read_all_data and pg_write_all_data roles are defined similarly, > with USAGE rights on all schemas. So, granting USAGE rights to > pg_maintain, but not the database owner, doesn't seem so odd to me. It doesn't seem so odd to me, either. But there are other things that could prevent a role with privileges of pg_maintain from being able to VACUUM a table. For example, the role might not have LOGIN, or it might not have CONNECT on the database. I think the argument for giving pg_maintain roles implicit USAGE on all schemas for only maintenance commands is that we already do that in some cases (e.g., a database-wide VACUUM). > I'd like hear more opinions about this. +1 -- nathan