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 1rkTPU-00CyN9-77 for pgsql-bugs@arkaria.postgresql.org; Wed, 13 Mar 2024 18:33:04 +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 1rkTPS-00AOMA-JN for pgsql-bugs@arkaria.postgresql.org; Wed, 13 Mar 2024 18:33:03 +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 1rkTPS-00AOM2-Ax for pgsql-bugs@lists.postgresql.org; Wed, 13 Mar 2024 18:33:02 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rkTPQ-004LpM-CO for pgsql-bugs@lists.postgresql.org; Wed, 13 Mar 2024 18:33:02 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 42DIWthS2076080; Wed, 13 Mar 2024 14:32:55 -0400 From: Tom Lane To: Bruce Momjian cc: Laurenz Albe , Maxim Boguk , Heikki Linnakangas , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18387: Erroneous permission checks and/or misleading error messages with refresh materialized view In-reply-to: References: <18387-12041858d9efb6f6@postgresql.org> <36bb333d-13ec-4f8e-af33-48249ca2fe69@iki.fi> <09970dbb6f95a34d9427c32b09517ea709c77d02.camel@cybertec.at> Comments: In-reply-to Bruce Momjian message dated "Wed, 13 Mar 2024 13:08:09 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2076078.1710354775.1@sss.pgh.pa.us> Date: Wed, 13 Mar 2024 14:32:55 -0400 Message-ID: <2076079.1710354775@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Bruce Momjian writes: > On Tue, Mar 12, 2024 at 01:22:33PM +0100, Laurenz Albe wrote: >> I don't see why it should be a problem if a superuser gets >> "permission denied" in such a case. They can also get it if >> they call a SECURITY DEFINER function owned by a non-superuser. > Can we improve the error that superusers get so they realize how to fix > it? I think there's been a policy of being minimalistic on permission-denied errors to avoid giving away security information, but I'm not sure how much sense that really makes. We already show the specific object that didn't have permissions. I think it would be good for these errors to also mention the specific role whose permissions were checked. Perhaps also show the specific privileges that were missing --- although it might be hard to do that in a non-confusing way for complicated cases, such as queries that are valid if you have either table- or column-level permissions. If we just add the role I'd envision ERROR: permission denied to role "foo" for [object] although with any more detail that would get too long. Another way could be ERROR: permission denied for [object] DETAIL: Role "foo" lacks permission [permission]. Mentioning the role that was checked should address the concern of "I'm a superuser, why did I get this error?". However, fixing it requires knowing which privilege to grant. I'm not sure if that's always obvious. regards, tom lane