On Wed, Jul 12, 2017 at 07:38:56AM -0500, Robert Haas wrote:
> On Tue, May 9, 2017 at 9:43 PM, Chapman Flack <chap@anastigmatix.net> wrote:
> > That's where the appident.cookie() function comes in. You just
> > query it once at session establishment and remember the cookie.
> > That allows your code to say:
> >
> > SET SESSION ON BEHALF OF 'joe user' BECAUSE I HAVE :cookie AND I SAY SO;
> >
> > and Mallory can't inject that because he doesn't have :cookie and the
> > appident.cookie() function only succeeds the first time.
>
> I have for a long time been interested in having a protocol-level
> method for setting the session identity. That is, instead of sending
> "SET SESSION AUTHORIZATION 'rhaas'" wrapped in a Query message, you'd
> send some new protocol message that we invent that nails down the
> session authorization and doesn't allow it to be changed except by
> another protocol message. I feel like the usefulness of this for
> connection pooling software is pretty obvious: it's a lot easier for
> the pooler to disallow a certain protocol message than a certain SQL
> command.
Neat idea.
> But maybe we could generalize it a bit, so that it can work for any
> GUC. For example, let the client send some new SetVariableViaProtocol
> message with two arguments, a GUC name and a value. The server treats
> this just like a SET command, except that once you've done this, the
> variable can't later be changed from SQL. So now you don't even need
> the cookie, and the client can't try to guess the cookie. You just
> tell the server - via this protocol message - to nail down
> session_authorization or application_name or appuser.thunk to some
> value of your choice, and it's invulnerable to SQL injection
> thereafter.
Likely to SQL injection. I guess that would direct attackers to the
protocol, which I suppose is already a harder target, assuming SSL or
similar.
> Whaddaya think?
I thing I'm not alone in wanting some way to set parameters and hold
them steady. I confess I'd been thinking more in terms of a DCL for
these, but that makes it a lot less flexible than what you're
proposing in the sense that it's set on connect rather than via GRANT
and REVOKE.
One thing I'm not seeing how to do via your proposal is to hold these
things for local (not localhost) users. Is there some way to handle
them, too, or would that be over-engineering this, given what a local
user can already accomplish?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
