Re: RFC: Security documentation

From: "Alex J(dot) Avriette" <alex(at)posixnap(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFC: Security documentation
Date: 2004-02-08 23:42:38
Message-ID: 20040208234238.GB12909@posixnap.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)posixnap(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2004-02-09 01:01:38 Re: RFC: Very large scale postgres support
Previous Message Simon Riggs 2004-02-08 23:29:47 Re: [PATCHES] update i386 spinlock for hyperthreading