Re: ZEO authorization model?

> On May 25, 2016, at 09:08, Jim Fulton <[email protected]> wrote:
> 
>>> I was thinking that the
>>> access control would be pluggable and would moderate load, create and
>>> update operations.
>> 
>> I'm curious what you were thinking there. Would it operate at the level of the pickled bytes and OID? It seems to be that's not very much context to make decisions on. Unless the plugin was to unpickle each object? Aside from the overhead, that assumes that the client code is loaded in the ZEO process, and I thought one of the upcoming goals was to move conflict resolution to the client so as not to require the client code to be loaded in the ZEO process. Also, some common authorization schemes I've use (Pyramid's ACLs and zope.security) use not just an object in isolation, but the entire parent tree to make decisions, so they wouldn't be useful operating on just a single object/operation.
> 
> No, I wouldn't use the pickled data record.  This would only use the
> oid and grants associated with the oid, and possibly tid.  Create
> decisions would be database wide. That is, a user would be able to
> create or not in a database. An example of a very simple model is one
> in which any user can create and users are only able to load or update
> oids they created.  It's an open question where grant data would be
> stored.

Got it, I think I see what you're saying. So the creating user would have to be persisted along with each OID.

There are some issues with that (admittedly very simple) model. Consider a zope.index system using event-based indexing. A given connection+user may create a content object which has the side-effect of adding new buckets to the index objects (and thus be stored as the creator of them). Some other connection+user could create or update a completely different content object, and if it uses the same index objects as the first connection, that operation would be blocked. I suspect a lot of non-trivial applications have this kind of "shared" object. It would be hard to distinguish those just based on a tid and oid, I think.


>> 
>> It also seems that authorization (and authentication too, come to think of it) would either have to disable the client-side persistent cache, or encrypt it based on a user-specific token issued by the ZEO server after authorization is complete.
> 
> Given that a cache is associated with a connection and a connection
> with a user, all of the data in the cache would have to have been
> readable by the user, at least as of the time it was read.  Perhaps
> I'm misunderstanding you.

Right, *at the time it was read*. Suppose you connect with user A and read a bunch of data. This data gets written to disk in the persistent cache. If you later alter the configuration to connect with user B, user B's connection will have load access to all of the data in the persistent cache populated by user A even if it shouldn't (because when the client loads from the persistent cache, it completely bypasses the ZEO server). Somehow associating the connecting user with the persistent cache and verifying they match prevents this problem. In this scenario, encrypting the persistent cache based on the user token is simply another way to keep the data in the file safe if operating system permissions are not set appropriately.

Another scenario is that the server's grants for user A change so that it should no longer be allowed to load some subset of the data it previously could. Unless there's some mechanism for restricting the cache file based on the servers grants (such as encrypting it based on the a token issued by the ZEO server, derived from the grants, somehow), the client could still load data it no longer should. Here, encrypting the file is important even if the file permissions are appropriate.

Maybe these are far-fetched scenarios (especially the second), and all the people and users connecting to a ZEO server are trusted. But then, what problem is authorization trying to solve? :) A partial solution seems worse than no solution, I think, because it yields a false sense of security.

One could argue that a similar problem exists in a traditional database; you could connect and do "'SELECT * FROM table' > file.data" and have a cache of the data at a particular point in time. But that data is offline and separate from the process of actually connecting and talking to the server. The persistent cache is an integral part of using ZEO, so it needs to ensure that whatever authorization guarantees the ZEO server makes are still respected.

Jason

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.