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

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?

Regards,
--
-David
david(at)pgmasters(dot)net