Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Date
Msg-id 006301c0f083$77eda960$d7d310ac@jecw2k1
Whole thread Raw
In response to Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
List pgsql-hackers
> > ISTM the name-based variants will primarily be used for user-entered
> > names, and in that case the user can reasonably expect that a name
> > will be interpreted the same way as if he'd written it out in a query.
>
> That would be correct if the user were actually entering the name in the
> same way, i.e., unquoted or double-quoted.
>
> > The nextval approach is ugly, I'll grant you, but it's also functional.
>
> But it's incompatible with the SQL conventions.
>

Is the concern that the name-based variants of the function should be called
like:
  select has_table_privilege(current_user, pg_class, 'insert');    or  select has_table_privilege(current_user, "My
QuotedRelname", 'insert');
 

instead of
  select has_table_privilege(current_user, 'pg_class', 'insert');    or  select has_table_privilege(current_user, '"My
QuotedRelname"',
 
'insert');

?

If so, what would be involved in fixing it?

From an end user's perspective, I wouldn't mind the latter syntax, although
the former is clearly more intuitive. But I'd rather have the second form
than nothing (just MHO).

-- Joe




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR: Memory exhausted in AllocSetAlloc(909324558)
Next
From: Mike Cianflone
Date:
Subject: Strange behavior on multiple primary key behavior deleting childr en