Re: RFC: Security documentation - Mailing list pgsql-hackers

From Alex J. Avriette
Subject Re: RFC: Security documentation
Date
Msg-id 20040208234238.GB12909@posixnap.net
Whole thread Raw
In response to Re: RFC: Security documentation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: RFC: Security documentation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Feb 08, 2004 at 01:33:31PM -0500, Tom Lane wrote:

> > Actually I can and it involves changing the backend to not permit multiple
> > statements in one request. I can't imagine how that could sensibly be
> > implemented, if at all, though.
> 
> Actually, the extended-query message in the new FE/BE protocol works
> exactly that way.  This was done for protocol-simplicity reasons not for
> security, but you could use it for that.  The new protocol's ability to
> separate parameter values from SQL command is also useful for ensuring
> security.

(Tom is referring to this: http://archives.postgresql.org/pgsql-interfaces/2003-03/msg00017.php)

How would you suggest implementing this? Having a "no subqueries" setting?
Asking the postmaster to throw an exception on queries-within-data? I 
can think of several ways to do it, but I'd like to know what you had in 
mind.

> > At some stage your interface code has to accept responsibility for preventing
> > dangerous input from reaching libpq.
> 
> However, I quite agree with that statement.  The app programmer has to
> take responsibility for properly segregating or quoting data strings.
> We can (and do) provide tools to make this easier, but it's still the
> programmer's responsibility to use the tools correctly.

I agree with this as well. In my original message, I complained that there
was no documentation at all. Since we offer documentation on how to code
in plpgsql, pltcl, plperl, etc., it might be nice to include something.
Even if it were something brief, such as suggesting escaped quotes and
other suspicious characters, it would be better than the nothing that is
there presently. Like I said, it allows some disclaiming of culpability
for the programmer -- "I did what the docs said" -- and it gives them
an idea of where to start.

My initial feeling is that a small addition to the 'Server Programming'
section would be reasonable, or perhaps in the Appendix.

I can't see why anyone would be opposed to this, however. I'm happy to
write the document and provide a patch for inclusion if we can come to
agreeance on some basic policies. The reason I posted the original 
message in this thread is I wanted to know what others felt were 
appropriate policies, and to suggest said policies wound up in a doc.

Alex

--
alex@posixnap.net
Alex J. Avriette, Unix Systems Gladiator
"I favor the Civil Rights Act of 1965, and it must be enforced at gunpoint if necessary." - Ronald Reagan


pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: [PATCHES] update i386 spinlock for hyperthreading
Next
From: Rod Taylor
Date:
Subject: Re: RFC: Very large scale postgres support