"Richard Huxton" <dev@archonet.com> writes:
> I'm guessing there's a Good Reason (TM) why setting permissions on pg_class
> et al don't seem to work.
Well, I dunno if it's a *good* reason, but none of the low-level
operations on system catalogs pay any attention to permissions on
the catalogs (nor to rules or triggers, if one were to try to set
such things on the catalogs). We would get into some interesting
definitional issues if we tried to make that happen. For example,
if I forbid you read access on pg_class, how does that get enforced?
(You'd have to read pg_class to discover the prohibition, after all.)
If I forbid you write access on pg_index, does that mean you can't
create indexes on your own tables? If I forbid you read access to
pg_relcheck, does that mean that you're suddenly able to do inserts
that violate constraints (since you can't see the constraints anymore)?
If I create an ON SELECT rule on pg_rewrite that alters the apparent
contents of pg_rewrite so as to hide itself from view, does that rule
actually get applied?
The implementation problems would be even more interesting ;-)
> Failing that, is Dan's talk of triggers (other branch of this thread)
> plausible?
See above.
> Some disgusting hack to the client libraries to disable CREATE...
> and ALTER TABLE?
Rather pointless, since an attacker could bypass it just by using a
de-hacked client library.
regards, tom lane
