>One compromise might be that we refuse to run with elevated privs on
Windows
>if configured to listen on more than localhost. Then developers with admin
>privs could play happily, but server admins would need to do the Right
Thing
>(tm). Of course, if another local service could be induced to do bad
things
>via postgres that would be no protection, but at least we would not be the
>primary attack vector.
Andrew,
I got the same problem with postgres and Adminsitrator Privs on Windows,
and know that Admin on Windows is "quite usual".
I also thought of that solution - to recommend postgresql just to listen
to localhost when running with admin privs.
But that is of no use:
1) Usual webserver, PHP or whatever, postgresql on same host. Some flaky
php design, and you can attack via SQL-Spoofing with the requests coming
from localhost
2) somebody got shell access via some other security hole in IIS or
whatever. Now he could use local postgresql for privilege elevation.
I'm also not very lucky about postgresql not running with Admin privs,
but after thinking and listening to the arguments, I would recommend
that we focus our energies to make it totally easy to "automagically do
the right thing", maybe even "if run as Admin, create Postgresql user
with no rights and run as Postgres"
Harald
