Re: [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?

> > http://archives.postgresql.org/pgsql-patches/2003-07/msg00204.php
> > Sure sounds like you said READ ONLY xacts can't be used for security. :)
>
> Better read it again then.

Okay:

>> It's not intended to be a security measure, and I would strongly
>> resist any attempt to make it so along the lines you propose.

And "strong resist" in tgl-speak means, "over my dead body, it ain't
gunna happen." :)

> > I think Tom's big objection is the abuse of the GUC system for
> > maintaining this information.
>
> Check.
>
> > Having thought about this some, I think the GUC system is pretty
> > well suited for this and that Tom's objection (correct me if I'm
> > wrong here) is that GUC has a non-hierarchical naming
> > structure/convention.
>
> Not in the least. My objection to using GUC for this is that it's
> not designed to be non-subvertible; rather it's designed to allow
> settings to come from nearly anywhere. To get around that, you have
> to kluge it horribly. Poster child, once again, the cruft Bruce put
> into the logging settings --- not only is that ugly, but I have very
> little confidence that it doesn't still have holes. Complexity is
> not a virtue in security-related code; and any security expert will
> tell you that having the same code serving both security- and
> non-security-related goals is a recipe for disaster. It's too easy
> to break security while you are fooling with something you think is
> unrelated.

Far be it for me to disagree with your points. Can I clarify what
you're saying then with the following statement:

"A GUC-like system that is specific for containing security related
settings would be okay, but GUC as it stands in its current
incarnation, should not (at least with any illusion of providing
security) be used for anything that is security related."

And if I'm wrong in those assertions, can you comment on how you would
do this with a tunable definition of "read only?" And if you agree
with the above statement, do you have any thoughts on improving GUC so
that it could potentially be more secure or secure enough? Anything
that is written in C clobbers any attempt at being secure. What in
side of the backend do you trust? -sc

--
Sean Chittenden