Message-Id: <9302041646.AA16734@postgres.Berkeley.EDU>
From: aoki@postgres.Berkeley.EDU
Subject: Re: Enhanced Security in 4.1?
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Thu, 4 Feb 93 07:47:05 -0800 
	     <9302041547.AA16440@postgres.Berkeley.EDU> 
Date: Thu, 04 Feb 93 08:49:07 -0800
From: aoki@postgres.Berkeley.EDU

> Will Postgres 4.1 have enhanced security features? 
> If so, can we get a preview of what they will be like?

Class owners will be able to define access control lists specifying
read/write/append(special case of write, obviously)/define rule
permissions at the class level (only).  The notion of groups has 
also been added to make this a bit easier.

Untrusted functions have been implemented.  This code will undoubtedly
go through changes between 4.1 and 4.2, so I decided not to make newly 
defined functions default to untrusted.

Note that the last sentence implies a security hole in the ACL scheme.
(Remember that trusted functions run inside the server address space.)
Eventually, untrusted functions will be the default and another ACL
for function definitions will be added.

I added some network authentication hooks for use of Kerberos v4 and v5.
This code only does authentication upon initial connection -- the 
frontend/backend protocol implementation is so ad-hoc that I punted on
trying to secure (encrypt) the data traffic (read: I got lazy).  Still,
one would hope that this would at least keep J. Random Hacker (who's 
working at the telnet level instead of the packet level) out of your 
postmaster.

At this point, these features should be considered experimental features 
that are subject to change with user feedback, but at least they give you 
something to play with (and help prevent careless errors).

I trust no one's trying to use POSTGRES in a real Orange Book system ;-)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki