Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] [PATCH] Re: Why READ ONLY transactions?

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Browne <cbbrowne(at)libertyrms(dot)info>,pgsql-patches(at)postgresql(dot)org,Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>,Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-advocacy(at)postgresql(dot)org
Subject: Re: [PATCHES] [PATCH] Re: Why READ ONLY transactions?
Date: 2003-07-30 23:42:31
Message-ID: 20030730234231.GI34647@perrin.int.nxad.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackerspgsql-patches
> >> 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

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2003-07-31 00:38:21
Subject: Re: Is Patch Ok for deferred trigger disk queue?
Previous:From: Tom LaneDate: 2003-07-30 23:29:37
Subject: Re: [PATCHES] [PATCH] Re: Why READ ONLY transactions?

pgsql-patches by date

Next:From: Joe ConwayDate: 2003-07-31 00:02:47
Subject: Re: hexadecimal to decimal
Previous:From: Tom LaneDate: 2003-07-30 23:29:37
Subject: Re: [PATCHES] [PATCH] Re: Why READ ONLY transactions?

pgsql-advocacy by date

Next:From: Bruce MomjianDate: 2003-07-31 01:29:37
Subject: Re: [PATCH] Re: Why READ ONLY transactions?
Previous:From: Jean-Michel POUREDate: 2003-07-30 23:41:27
Subject: Re: Draft #5 -- radically re-written

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group