> >> Why?  If we refuse to run as root on Unix, I do not see an 
> argument 
> >> for being more forgiving on Windows.
> > I am not sure it is as easy to run as non-admin on Win32 as 
> it is to 
> > run as non-root on Unix.  Is it?

It is a little bit more tricky, but not much. I'd say it's more a factor
of what people are used to. People think of their windows machine as a
single user system, and their unix machine as a multi user system.

On Windows 2000+ you can have multiple windows on the same windowstation
running as different users (using runas). In <= NT4 you can only have
services running as a different user than the one logged on to the

> Ease of use has nothing to do with this.  Given the 
> demonstrated security weaknesses of Windows, we would be 
> completely irresponsible to allow Postgres to be started in 
> an obviously-insecure way on that platform.

Certainly a good argument. I was more into emulating the behaviour of
the other available databases for windows. They normally *let* you run
with high-priv accounts, but they *recommend* you don't. This is pretty
much standard for most "respectable" windows products.

In production, you certainly wouldn't do it. But it helps if you're
setting it up in a lab for testing, for example. When you *know* what
you are doing.

But it can certainly be changed to an ERROR if we want. I'd still argue
it should go at this place and not earlier, because we want to get the
output to go where we want it. See below.

> In other words, I do not wish to be the author of code that 
> could become the vector for the next SQL Slammer worm.

While I fully agree with that statement, it is an incorrect comparison.
The Slammer worm was because of a hole in SQL Server that allowed
arbitrary code execution as whatever user account SQLServer was running
as. It spread equally on server running as Local System, with admin
privileges or (as recommended) with a low-privilege account. You don't
have to be an administrator to send out UDP packets...

A similar worm could just as easily hit postgresql on Unix today (eh,
assuming such a security hole existed, which I'm fairly sure it doesn't,
but hypothetically). It's not a factor of the platform. It's a factor of
the product.

Local admin privs will let a security hole in *postgresql*
change/destroy parts of the *local operating system*. No more, no less.
(Unless you give it domain admins, in which case in can reach other
machines in the domain, of course)

> I am already deathly afraid of what the Windows port is 
> likely to do to Postgres' reputation for reliability and 
> security.  Do *not* get me started by proposing that we 
> insert obvious security holes on lame "ease of use" grounds.  
> Haven't the boys in Redmond already proven the wrongness of 
> those priorities many times over?

They certainly have. In some products (like SQL Server), they've now
moved to recommending against it. They're not outright preventing it. 

From other mail:
> We could move the Unix check later without any problem.  I agree with
keeping both checks 
> in the same place.

I read this as that you'd prefer to see the Unix "check-for-root"-code
moved to the same place? If so, I'll update the patch with that,
depending the outcome of the rest of the discussion (for example, need
for ereport)


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to