[ZODB-Dev] ZEO and Security

Bill Anderson bill@libc.org
07 May 2001 13:35:33 -0600


On 07 May 2001 11:06:20 -0700, Michel Pelletier wrote:
> On 7 May 2001, Bill Anderson wrote:
> 
> > On 07 May 2001 10:09:34 -0400, Chris McDonough wrote:
> > > Ssh tunnelling is an effective workaround for now.
> > 
> > Not really, as that just encrypts the traffic from the client. it does
> > nothing to prevent, say, Bob from doing things he should do,such as
> > messing around with Joe's data.
> 
> Security is outside the domain of the database.  ZODB does not know

Since when??

Pretty much all RDMS servers I've used have a security mechanism.

> anything about Bob or Joe or any other object for that matter, and it
> would be a pain to try and teach it (and probably a bad idea in
> general) application level constraints like security.

I think it will pretty miuch be a requirement, for reasons I've already
stated.

> If you want security like the Zope application enforces, then you need to
> either duplicate that security in your app (ugh) or just use Zope as the
> ZEO client.  Zope's interfaces are now HTML, but there's no reason why
> they could not be some GUI framework.  It sounds like what you are writing
> is more of a "ZODB-browser".  Probably an easier task yes, but not as
> useful.

Exactly, i don't want to go through and duplicate the zope security
machinerey, and the full extent of it is not even neccesary. it seems
anathema to the OS mantra of code reuse. Why should everyone reimplement
database security for each app? All we really need for basic security
9again, which is all that is ebing asked), is a hook, such that db
access goes through before being allowed to operate.

This applies to Zope as well. Right now, you have to use the Operating
System if you want to use any security in determining what other
machines can connect to your database. And it is important becuase if I
have a Zope setup, and connect it to your ZEO server, I have unlimited
access, I don't need you passwords, as I can set up my own access file
for emergency userness, and from there do what I wish.

Now, since Zope has no way of enforcing this (it being a ZEO thing),
there is some resistance to ZeoZope's acceptance as something you can
use to balance across arbitrary machines, such as a mirror system. 

I agree the problem may not be simple in code, but it is a big wart
awaiting discovery. As zope/ZEO/ZODB grows in popularity, it will not be
long before someone in 'the press' as it were, to hear of this, and at
Internet Speed, ZODB/ZEO/Zope get a bad mark next to them. 

Of course, you could techically say that ZEO is the app. In which case,
your argument that the app should deal with security still means ZEO has
to have some security awareness. Since in my case, and many others I am
aware of, we are talking about a client/server app, ZEO is the server,
and the GUI/whatever is the client. Servers should handle ALL of their
security, and NEVER allow the client to deal with it. That is too big of
a hole. Given that I don't know of any methods for connecting to ZEO
from C, any security my app implements will be in plain view of the
user. As such, it is up to the user to:
A) Keep the source from prying eyes (not possible in OpenSource)
B) Not do anything that circumvents the security

In the case of an app using _just_ ZODB, I agree, it is the app's
repsonsibility. That is why I aimed at ZEO. Sure, I can continue to use
PostgreSQl and psycopg to develop apps, since PostgreSQl has security,
but I _think_ in more object oriented terms, not in relational algebra,
so I can be much mor eefficient and faster with ZODB/ZEO as the
underlying framework and storage.

Well, it appears I have started rambling, so I'll close up for now.

Bill