> >> I'm not objecting to the idea of being able to make users
> >> read-only. I'm objecting to using GUC for it. Send in a patch
> >> that, say, adds a bool column to pg_shadow, and I'll be happy.
>
> > How is that any different than ALTER USER [username] SET
> > jail_read_only_transactions TO true? It sets something in
> > pg_shadow.useconfig column, which is permanent.
>
> But it has to go through a mechanism that is designed and built to
> allow that value to be overridden from other places. I think using
> GUC for this is just asking for trouble. Even if there is no
> security hole today, it's very easy to imagine future changes in GUC
> that would unintentionally create one.
*nods* Anything that goes outside of SetConfigOption(), however, is
incorrectly setting a GUC value and can't really be prevented. At the
C level, nothing is safe and there's no way to make things 100% secure
(except for possibly by moving PostgreSQL over into protected mode).
If PostgreSQL can't trust itself, who can it trust?
If you're worried about someone setting JailReadOnlyXacts or
XactsReadOnly in a C extension, then let me hide those two variables
away in their own file, declare them static, and provide accessor
methods to the variables. It doesn't prevent someone from changing
their values if they know the address, but it'll at least prevent
someone from #include'ing a header and mucking with things. Would
moving things into their own files and declaring them static be a
sufficient compromise? I'll declare the accessor functions inline
too, that way there should be zero loss of performance given
XactReadOnly is frequently used. -sc
--
Sean Chittenden
