[ZODB-Dev] ZEO and access permissions

[Nitro]

Am 23.05.2010, 17:53 Uhr, schrieb Jim Fulton <jim at zope.com>:

>> Does it make sense at all or is it still
>> better to restrict access on the application level?
>
> I would do it at the storage level, not in the application nor in ZEO.
>
> It is probably possible with some sort of wrapper storage.  There are
> lots of details to be worked out.  This is a project I've been looking
> forward to working on for some time, but it is still prettty far down
> on my list.

Thanks for Hanno's and your answer. They are quite different :-) I've  
thought a lot more about both approaches. Yet reaching a conclusion is  
quite hard. I'll present you some of my reasoning below.

I'll elaborate a bit more on the current design of my application: In the  
context of my application "security" does not mean 100% secure against any  
kind of attacker, it's more a simple method to prevent some people from  
seeing other people's things. And to prevent accidental changes. The  
people are all more or less trusted.

My system consists of a server (zodb + twisted) and various desktop  
clients. The zodb part of the server is used for storing the data, the  
twisted part is used for event sending and various other communications  
between clients. All the major work on the data happens on the clients,  
the server is pretty dumb.

Until I thought about security I was assuming the desktop clients could  
directly access the zodb via ZEO. This would have made many things easy.  
Clients could access the database directly, manipulate the data model and  
send events accordingly. Other clients receive the events and can update  
their views by pulling the changed data from the database.

With security in mind, the design has to change. Let's consider a simple  
example of a Folder object with a few sub-folders. The client will send a  
request to the server "get all children of folder X". The server will  
check if the user has access to folder X and will then return all the  
sub-folders to which the client has access to. With the previous model  
this would've been as easy as doing "print folder.subfolders", ZEO would  
take care of returning subfolders. Of course ZEO will not filter the  
subfolders list by security permissions.

Taking this example a step further, if the client wants to add a new  
folder, he will have to perform an action "add folder" which takes the oid  
of folder X and the name of the new folder (+ other parameters). The  
server receives the command, checks if the user may add the new folder and  
finally adds it. If the transaction succeeded the server then sends an  
event "folder X subfolders changed". The client receives this event and  
then issues the "get all children of folder X" event again to update its  
view with the new folder.

Another complication: the client side needs a cache. When it receives an  
answer to "get all children of folder X" the result should be remembered  
until the client receives an event that the children of folder X have  
changed. The cache should also be persistent between different runs of the  
clients, because building the cache from 0 means the client possibly has  
to download gigabytes of data (over a broadband internet connection, not  
LAN speed style). It's also a bit unclear to me how to maintain  
inter-references between objects if the server never returns objects  
directly.
The client's "cache" is more like a local database which should be in sync  
with the server's db. There can be differences between server and client  
db, because of the differing security permissions.

Synced db between client and server, notifications when objects change,  
client side cache. Does all of this sound familiar? ZEO provides all of  
this. Except the security part.

To summarize, if I'd go the application level security route (Hanno's way,  
implementation as I proposed above):

- Check permissions on the server in all relevant places (e.g. each time a  
folder is accessed by someone)
- Client cannot access db directly, has to use indirect commands which the  
server executes on the client's behalf
- Layer to serialize and transport objects from server to client and  
vice-versa
- Custom client cache implementation
- Unclear how the db as a whole (intra-references) is represented on the  
client

Integrating into ZEO:

- Clients could access db directly
- Unclear how this can be implemented. ZEO client sees only proxies of  
real server objects? Proxies/views would restrict the access on the client  
side (e.g. a folder proxy would provide only a filtered view on all the  
subfolders). This is a bit similar to OO RPC calls. E.g.  
http://pyro.sourceforge.net/ and twisted's perspective broker provide  
something along these lines.

I'd be willing to spend time on implementing something like this if we can  
work out a proposal together of how to do things exactly.

-Matthias