Re: "has_column_privilege()" issue with attnums and non-existent columns

From: Joe Conway <mail(at)joeconway(dot)com>
To: David Steele <david(at)pgmasters(dot)net>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "has_column_privilege()" issue with attnums and non-existent columns
Date: 2021-03-03 14:43:16
Message-ID: f65254e5-a38e-e418-266a-f29293b941e7@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/3/21 8:50 AM, David Steele wrote:
> On 1/29/21 4:56 AM, Joe Conway wrote:
>> On 1/29/21 12:13 AM, Ian Lawrence Barwick wrote:
>>> 2021年1月28日(木) 17:18 Peter Eisentraut:
>>> I'm not convinced the current behavior is wrong.  Is there some
>>> practical use case that is affected by this behavior?
>>>
>>> I was poking around at the function with a view to using it for something and was
>>> curious what it did with bad input.
>>>
>>> Providing the column name of a dropped column:
>>>
>>>     Me: "Hey Postgres, do I have privileges on the dropped column 'bar' of my
>>> table 'foo'?"
>>>     Pg: "That column doesn't even exist - here, have an error instead."
>>>     Me: "Hey Postgres, does some other less-privileged user have privileges on the
>>>          dropped column 'bar' of my table 'foo'?
>>>     Pg: "That column doesn't even exist - here, have an error instead."
>>>
>>> Providing the attnum of a dropped column:
>>>
>>>     Me: "Hey Postgres, here's the attnum of the dropped column 'bar', does some
>>>          other less-privileged user have privileges on that column?"
>>>     Pg: "That column doesn't even exist - here, have a NULL".
>>>     Me: "Hey Postgres, here's the attnum of the dropped column 'bar' on this table
>>>          I own, do I have privileges on that column?"
>>>     Pg: "Yup. And feel free to throw any other smallint at me, I'll pretend that
>>>          represents a column too even if it never existed.".
>>>
>>> Looking at the code, particularly the cited comment, it does seems the intent was
>>> to return NULL in all cases where an invalid attnum was provided, but that gets
>>> short-circuited by the assumption table owner = has privilege on any column.
>>
>> Nicely illustrated :-)
>>
>>> Not the most urgent or exciting of issues, but seems inconsistent to me.
>>
>> +1
>
> Peter, did Ian's explanation answer your concerns?
>
> Joe (or Peter), any interest in reviewing/committing this patch?

Sure, I'll take a look

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2021-03-03 14:44:09 Re: jsonpath syntax extensions
Previous Message Amit Langote 2021-03-03 14:39:01 Re: making update/delete of inheritance trees scale better