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 1sQdt2-00AtES-I2 for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jul 2024 02:13:52 +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 1sQdt0-00HQ9W-Fl for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jul 2024 02:13:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sQdt0-00HQ9O-6H for pgsql-hackers@lists.postgresql.org; Mon, 08 Jul 2024 02:13:50 +0000 Received: from mail-io1-xd2e.google.com ([2607:f8b0:4864:20::d2e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sQdsx-000wKq-N2 for pgsql-hackers@lists.postgresql.org; Mon, 08 Jul 2024 02:13:48 +0000 Received: by mail-io1-xd2e.google.com with SMTP id ca18e2360f4ac-7fb93b2e2a3so32849139f.1 for ; Sun, 07 Jul 2024 19:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720404827; x=1721009627; 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=xXQDqiNTMbju/JgXVSupf9ezT2JgGyaxPW9ZlXedzqE=; b=d3/T+dflCINcMLniRmd1wp4HKGtAgxN51IbPdlzsiwu23Ot9+FKXaJu6YbZa3l2abG swnHDKDNbu2AmItvf4bByuyfDdkR0Tw49NRHWqv4uBM3u3OAyJaEIeirjEm1iH3reaeK TLrHeoIau8MB89y2V0t+4SlcxkeIDJGEX0CrszHetNEcOQx1tX6pZlOb5BcnfOPXUmaS HKbj+67MTpgLecQ38LYHuDhd7KaIRaMkReeZt3Aaa88TTaH24VAVj+Bt91pucojqXA19 4uup5fbj8iYKjJBF2NPvY1FjAwzs/SRz4sWc1AXYsqEifvTuJZmt11tzVVuQdHVZjix7 69Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720404827; x=1721009627; 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=xXQDqiNTMbju/JgXVSupf9ezT2JgGyaxPW9ZlXedzqE=; b=wkOp1yd9qz5vUBoE/wNYqj+PeCRKapYfaZIVxGcdhLbswR154G3Cqjq/UV3tpTOJUA rbt5+wdeWtfG5yymF/Bkt4gUMGq6oCyHpj/AIc8l6MFU8CiRAnKBsuMwPNRaD46DXSVH jI1qRI1JePoGm10eBQfYVSemhch325kxH/aOZuwpDU+nGZkTPogTxPMFX3nrexRYBebc JTzPHrTFcE66+D3DuHUSKHFhvuebXmV48TVp5FLDz0VL/lDWweYa4BRe3mO82MP7lY9P pEdZFteihgjAZ2SBWuzP9TttbhY9+u08da3WTE8UWJra1MrHv9Qth4gUiapqpAGCnULi lgAQ== X-Gm-Message-State: AOJu0YxJKPMj/nhvmy5yXCYWCOLfyOE/Igp/Fecz9qlgfjiSCci3nv7Z 3CgReGRO4g5Vttwn22ItcC/rzPi1OIFj/v6z1j96go757Oh+hFc2RExNpH+h X-Google-Smtp-Source: AGHT+IFjfER03YnSkOU+1YDA3jmuRpwAu/pp2oNK/TTj/QGl/y9aWMPN8f1zLf1WOgOUUkGueL32zQ== X-Received: by 2002:a05:6602:158e:b0:7eb:4b89:b706 with SMTP id ca18e2360f4ac-7f66dead2a1mr1479968939f.8.1720404826759; Sun, 07 Jul 2024 19:13:46 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-7f61cec4b1bsm596861439f.33.2024.07.07.19.13.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jul 2024 19:13:46 -0700 (PDT) Date: Sun, 7 Jul 2024 21:13:44 -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: <56596b81-088f-4c0c-9a88-b5f27a7a62e9@oss.nttdata.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Jul 08, 2024 at 01:03:42AM +0900, Fujii Masao wrote: > I've noticed an issue with non-superusers who have the pg_maintain role. > When they run VACUUM on a specific table within a specific schema, > like "VACUUM mynsp.mytbl", it fails if they don't have the USAGE privilege > on the schema. For example, the error message logged is > "ERROR: permission denied for schema mynsp". However, running VACUUM > without specifying the table name, such as "VACUUM", > completes successfully and vacuums all tables, including those in schemas > where the user lacks the USAGE privilege. > > Is this behavior intentional? I'd consider it intentional because it matches the database owner behavior. If the database owner does not have USAGE on a schema, they'll similarly be unable to VACUUM a specific table in that schema while being able to VACUUM it via a database-wide command. That's admittedly a little weird, but IMHO any changes in this area should apply to both pg_maintain and the database owner. > I assumed that a pg_maintain user could run VACUUM on specific tables > in any schema without needing additional privileges. So, shouldn't > pg_maintain users be able to perform maintenance commands as if they have > USAGE rights on all schemas? It might be reasonable to give implicit USAGE privileges on all schemas during maintenance commands to pg_maintain roles. I would be a little hesitant to consider this v17 material, though. There are some other inconsistencies that predate MAINTAIN that I think we ought to clear up at some point. For example, the privilege checks for REINDEX work a bit differently than VACUUM, ANALYZE, and CLUSTER. I doubt that's causing anyone too much trouble in the field, but since we're grouping these commands together as "maintenance commands" now, it'd be nice to make them as consistent as possible. -- nathan