On Sun, Mar 2, 2014 at 6:20 AM, Noah Misch <n...@leadboat.com> wrote:

> On Sat, Mar 01, 2014 at 05:51:46PM -0500, Andrew Dunstan wrote:
> > On 03/01/2014 05:10 PM, Tom Lane wrote:
> > >One other thought here: is it actually reasonable to expend a lot of
> effort
> > >on the Windows case?  I'm not aware that people normally expect a
> Windows
> > >box to have multiple users at all, let alone non-mutually-trusting
> users.
> >
> > As Stephen said, it's fairly unusual. There are usually quite a few
> > roles, but it's rare to have more than one "human" type role
> > connected to the machine at a given time.
> I, too, agree it's rare.  Rare enough to justify leaving the vulnerability
> open on Windows, indefinitely?  I'd say not.  Windows itself has been
> pushing
> steadily toward better multi-user support over the past 15 years or so.
> Releasing software for Windows as though it were a single-user platform is
> backwards-looking.  We should be a model in this area, not a straggler.

Terminal Services have definitely become more common over time, but with
faster and cheaper virtualization, a lot of people have switched to that
instead, which would remove the problem of course.

I wonder how common it actually is, though, to *build postgres* on a
terminal services machine with other users on it...

Not saying we can't ignore it, and I gree that we should not be a straggler
on this, so doing a proper fix wwould definitely be the better.

> I'd be happy doing nothing in this case, or not very much. e.g.
> > provide a password but not with great cryptographic strength.
> One option that would simplify things is to fix only non-Windows in the
> back
> branches, via socket protection, and fix Windows in HEAD only.  We could
> even
> do so by extending HAVE_UNIX_SOCKETS support to Windows through named
> pipes.

That could certainly be a useful feature of it's own. But as you say,

 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Reply via email to