Subject: Re: Using Postgres from Unix and security

From: Rod Rebello -- CAD Development <[email-masked]>
Date: Wed, 6 May 1992 08:21:49 -0700

Stuart Pook said:
> You write:
> > > I have compiled and installed postgres, run initdb, launched a
> > > postmaster, and created a database called foo.  I have not run createuser.
> > > I find that any user can run "/usr/postgres/bin/monitor foo" and change
> > > the contents of the database foo.  This behaviour does not seem to agree
> > > with the documentation cited above.  Am I confused?
> > 
> > No, this isn't supposed to happen.  What machine do you use?
> 
> This letter is an addition to my previous letter.  On my Sun SPARC
> createdb seems to understand that the unix user "slp" is not
> authorised to connect to postgres but the monitor allows slp to
> read (and modify) the database "foo".  The following demonstrates this:

I have also not run createuser, yet we have not had any problems with access.
We are using Sun Sparcs. We are still on postgres 3.0. I have 3.1, but have
not gotten around to installing it yet.

-- 
Rod Rebello
[email-masked]
Microchip Technology Inc., Chandler, AZ

---

From: Rod Rebello -- CAD Development <[email-masked]>
Date: Wed, 6 May 1992 10:00:28 -0700

Mike Olson said:
> 
> since kerberos supports authentication without resorting to super-user
> privileges, we'll take that approach for the officially supported release.
> however, your fixes do what you claim they do -- you can't crack the
> database system without cracking root somewhere on your subnet.
> 
> 					mike
> 

Does this mean we would have to implement the complete kerberos system on
our network to use this feature?  Sorry if this is a naive question, but
I know little about kerberos.  My impression is that it is a fairly large
package that would take a fair amount of effort to install and maintain.
I assume that this capability will be optional in postgres?

I would prefer to have a method with little overhead.

---

From: [email-masked]
Date: Wed, 6 May 92 13:47:48 -0700

Just to add my 2 cents to the debate - my MSDOS port of libpq currently
sends a username specified in the MSDOS environment and selects the
port and host based on two other environment variables.  Hence, this
subverts the proposed fix if you have PC's on your subnet since there is
no real concept of a protected port number when programming a PC.  You
can decide not to allow protected port connection from any PC, but then
you lose use of a number of programs that are the reason why you are
running TCP/IP networking with PC's in the first place.

PC's are very insecure beasts - any protocol that doesn't require *at least*
a password or key stored on a protected server to be known can be
subverted by anyone with a PC and some smarts anywhere on your subnet.

Your solution solves the "pure" case of unix machines, but how many of
us have the luxury of PCless environments?  I'm not overwhelmingly supportive
of using Kerberos, but it is certainly better than the current no protection
case.

	Dan Jones