Re: Log enhancement for aclcheck permissions failures

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Bingyu Shen <ahshenbingyu(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Log enhancement for aclcheck permissions failures
Date: 2021-05-01 05:12:45
Message-ID: CALj2ACUSLK3pyvr6R5MBfcKADMT-ToCNYRC2862XWqUOSd_ybQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 1, 2021 at 5:26 AM Bingyu Shen <ahshenbingyu(at)gmail(dot)com> wrote:
> Hi hackers,
>
> I was wondering if we can improve the error messages for acl permission failures.
> Current implementation to report errors is in "backend/catalog/aclchk.c"
> void aclcheck_error(AclResult aclerr, ObjectType objtype, const char *objectname);
>
> based on the AclResult type, it print log messages like
> "permission denied for schema %s"
> which tells the admins what could be the domain of the permission-deny,
> like table name or schema name.
>
> However, I find that the log messages *lack* more details, i.e., the
> *exact permission* that causes the permission-deny. For the novice users,
> they may end up over-granting the permission to fix the issues
> and cause security vulnerability in the database.
>
> I think the log messages can be better if we add some diagnostic
> information like which *role* is denied and what *permission* it lacks.
> This way the users know which permission to grant exactly
> without the trial-and-errors.

I think it's easy for users (even if they are novice) to know exactly
what permission they are lacking by just looking at the query. See,
the permissions we have in parsenodes.h with ACL_XXXX, they are quite
clear and can be understood by the type of query. So, I don't think
printing that obvious information in the log message is something we
would want to improve.

To know the current role with which the query is run, users can use
CURRENT_ROLE or pg_roles.

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-05-01 05:12:58 Re: Enhanced error message to include hint messages for redundant options error
Previous Message Justin Pryzby 2021-05-01 05:11:43 Re: New assertion failed in lazy_scan_heap() on mereswine