Re: Strange permission problem regarding pg_settings

Joe Conway <mail@joeconway.com> writes:
> Works fine here too, on RH9:

> testdb=> update pg_settings set setting='public' where name='search_path' ;
>   set_config
> ------------
>   public
> (1 row)

> testdb=> select relacl, relacl is null from pg_class where relname =
> 'pg_settings';
>   relacl | ?column?
> --------+----------
>   {=r}   | f
> (1 row)

Hm.  By rights it *should* fail, since the ACL is clearly not granting
UPDATE permissions to anybody.

The fact that it fails to fail seems to be because the rules on
pg_settings rewrite the UPDATE into DO INSTEAD NOTHING (which does
nothing, in particular makes no permission checks) and a SELECT,
which only requires read-permission on pg_settings.  This is probably
bogus and we ought to see what we can do about fixing it.  (And we'd
better fix initdb to grant UPDATE on pg_settings to public, too.)

Now, why does Florian see a permissions failure (which is really the
*right* behavior) when we don't?  He didn't say exactly which PG version
he was running, but I see a likely-related bug fix between 7.3.2 and
7.3.3:

2003-02-13 16:40  tgl

    * src/backend/rewrite/rewriteHandler.c (REL7_3_STABLE): Repair rule
    permissions-checking bug reported by Tim Burgess 10-Feb-02: the
    table(s) modified by the original query would get checked for the
    type of write permission needed by a rule query.

This fix may need to be rethought.  I'm not sure though where is a clean
place to plug in the UPDATE permissions check given that the rules for
this case do not generate any UPDATE query.

            regards, tom lane