> > 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 t
Sean Chittenden <[EMAIL PROTECTED]> writes:
> 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.
> I think Tom's big objection is the abuse of the GUC system for
> maintaining thi
Sean Chittenden wrote:
> I think Tom's big objection is the abuse of the GUC system for
> maintaining this information. 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-hierarchic
> > Josh Berkus wrote:
> >> I thought that this was rejected thouroughly by Tom some months ago. He
> >> argued pretty strongly that READ ONLY transactions were *not* a security
> >> feature and that trying to make them one would work very poorly.
>
> > I remember something like that, but I tho
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> I thought that this was rejected thouroughly by Tom some months ago. He
>> argued pretty strongly that READ ONLY transactions were *not* a security
>> feature and that trying to make them one would work very poorly.
> I remember
Josh Berkus wrote:
> Bruce,
>
> > This seems like a valuable feature, as others have mentioned. However,
> > should it also prevent changes to default_transaction_read_only?
> >
> > What is the use case for this functionality?
>
> I thought that this was rejected thouroughly by Tom some months a
Bruce,
> This seems like a valuable feature, as others have mentioned. However,
> should it also prevent changes to default_transaction_read_only?
>
> What is the use case for this functionality?
I thought that this was rejected thouroughly by Tom some months ago. He
argued pretty strongly tha
Sean Chittenden wrote:
> > > > Um, why not make it an actual full blown security feature by
> > > > applying the following patch? This gives PostgreSQL real read
> > > > only transactions that users can't escape from. Notes about the
> > > > patch:
> > >
> > > Way nifty.
> > >
> > > I vote i
This has been saved for the 7.5 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Sean Chittenden wrote:
> > > > Um, why not make it an actual full blown security feature by
> > > > applying the following
Tom, have you considered using PGC_USERLIMIT for the existing
default_transaction_read_only variable? You could allow admins to turn
it on and off, but non-admins could only turn it on.
---
Tom Lane wrote:
> Sean Chittenden
If we change default_transaction_read_only to PGC_USERLIMIT, the
administrator can turn it on and off, but an ordinary user can only turn
it on, but not off.
Would that help?
---
Sean Chittenden wrote:
-- Start of PGP sig
> >> 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
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> 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
>
> >> 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.
>
> > Intended or not, it does work.
>
> No, you just haven't thought of a way to get around it yet. When
> you do think of one, you'll be wanting us to contor
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> 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.
> Intended or not, it does work.
No, you just haven't thought of a way to get around it yet. When you do
think of one,
> > > Um, why not make it an actual full blown security feature by
> > > applying the following patch? This gives PostgreSQL real read
> > > only transactions that users can't escape from. Notes about the
> > > patch:
> >
> > Way nifty.
> >
> > I vote in favor of this patch (suitably documen
> > Um, why not make it an actual full blown security feature by
> > applying the following patch? This gives PostgreSQL real read
> > only transactions that users can't escape from. Notes about the
> > patch:
>
> Way nifty.
>
> I vote in favor of this patch (suitably documented & debugged)
> >> I would NOT call it a "security" provision, as it is fairly
> >> easily defeated using SET TRANSACTION.
>
> > Um, why not make it an actual full blown security feature by
> > applying the following patch?
>
> It's not intended to be a security measure, and I would strongly
> resist any attem
Sean,
> Um, why not make it an actual full blown security feature by applying
> the following patch? This gives PostgreSQL real read only
> transactions that users can't escape from. Notes about the patch:
Way nifty.
I vote in favor of this patch (suitably documented & debugged) for 7.5.
-
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> I would NOT call it a "security" provision, as it is fairly easily
>> defeated using SET TRANSACTION.
> Um, why not make it an actual full blown security feature by applying
> the following patch?
It's not intended to be a security measure, and I wou
> - Read only transactions, bringing a greater level of
> security to web and enterprise applications by protecting
> data from modification.
>
> >> This should be removed. Even though I added it to the press
> >> release, I've just realised it's not really a security meas
21 matches
Mail list logo
