Tom Lane said:
> 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:
Sorry for not specifing the exact postgres versions involved initially - I
believed that the problem were different default on redhat and debian, or
different compiling options...
RedHat-9: postgres 7.3.2-3
debian: postgres 7.3.2r1-5 (sid backport)
I tried setting the relacl for the pg_settings table to {=rw}, but I still
get permission denied. To double-check, I then set it to {=}, and this
lets not only the update fail, but also select now gives "permission
denied" (The correct behaviour I believe).
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
