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
