From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pl/pgsql enabled by default |
Date: | 2005-05-07 15:38:40 |
Message-ID: | 2877.1115480320@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)com> writes:
> Users can already define SQL functions by default, which certainly
> provides "programmable features". I'm not quite sure what you mean by
> "user exits."
> I guess I'm missing how pl/pgsql is a fundamentally greater security risk.
plpgsql has control structures (loops, IF); SQL functions don't.
That makes for a fundamental difference in the power of the programming
language ... at least according to CS theory as I was taught it. Now
admittedly the "primitive statements" of SQL are a lot more powerful
than the primitive statements usually considered in programming language
theory, but I think there is still a pretty significant difference in
capability.
An example of why this could be interesting from a security standpoint
is that, given access to pg_shadow, it'd be pretty trivial to write
a plpgsql function that tries to break user passwords by brute force
(just generate possible passwords, hash them, and look for a match).
I don't see any way to do that in plain SQL, at least not without a
pre-existing SRF to generate the trial passwords for you.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-05-07 15:45:02 | Re: [PATCHES] Patch for database locale settings |
Previous Message | Tom Lane | 2005-05-07 14:58:09 | Re: Patch for collation using ICU |