Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> Bill Moran wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> >
> > > Chris Ochs wrote:
> > > >
> > > > What if SET SESSION AUTHORIZATION could also accept a password so that non
> > > > superusers could switch to a different user? How difficult would this be?
> > >
> > > Well, the password would go over the wire unencrypted, causing a
> > > security problem.
> >
> > Only if encrypted transport is not enabled. With encrypted transport, it would
> > be as secure as anything else, right?
> >
> > Perhaps, it could only be available if transmission encryption is enabled? Then
> > again, there's a certain amount of "only the user can shoot his own foot" that
> > has to be accepted ...
> >
> > Just thinking out loud ...
>
> Yes, if you use SSH it is secure, but do we want clauses that are only
> useful in SSH mode?
Not to start an argument, but you could reverse that logic and say "Do you want
to hurt the smart, ssl users by not including helpful functionality that could
be dangerous to uneducated non-ssl users?"
IMHO, it really depends on the design philosophy that PostgreSQL follows. I'm
familiar with the strong push for stability, and I approve. But I'm not as
sure I have a feel for what developers think about this kind of thing.
If you made it a compile-time option, or made it disabled by default and
requires a special setting in postgresql.conf to enable. Would that be secure?
Not really, as stupid users would still enable it without understanding, and
there's always the possibility that a some packager would build it with
dangerous settings and distribute it widely.
(As a side note, I seem to remember a program that had a --shoot-my-own-foot
option to ./configure ... but I can't remember what it was ...)
So, the question becomes one of design philosophy (at least, I'm basing this on
the concept that actual implementation would not be too hard, correct me if I'm
wrong)
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
