[dvdkon]

Could you elaborate on "prior to the actual query"? Do you mean taking some rough queryable subset and then calling Zanzibar for each object in that subset? That's how I'm handling it right now, I just hoped others had a more scalable solution.

[joshuamorton]

No I mean that a user either has access to the database or not. If they do, you check access prior to the query. I think you're doing something related to row level permissions within a database.

And ultimately "Implementing side-channel secure row level security in a database" is a completely independent problem from "abstract authz checker, which is what zanzibar is. You might build a row level security infra atop zanzibar, but you'd probably do that within your database engine, with zanzibar serving as some sort of authz primitive.

[dvdkon]

From what I can see, Zanzibar is also intended for "row-level" access checks.

I also don't think it's such a separate problem. If you've got a set of authorization primitives, you should have some simple and foolproof way of applying them to various usecases. You might have the best policy description language and very fast evaluation, but what good is it as a central authz service when you can't securely implement search on top of it?

[joshuamorton]

> From what I can see, Zanzibar is also intended for "row-level" access checks.

Yes, as a primitive for storing acl relations, not as a magic solves all security problems tool.

I thought about this more, and I think your usecase is simply unsolvable. You're allowing an untrusted user to take speculative action on something they may not have access to.

This is the same problem as spectre (and similarly unfixable). You'd need to do the acl-checks per row prior to the checks on the internal data. That is, as part of the operation `WHERE id = 123`, you need the database engine to check that you have access to the row, and only if they are acl'd, allow the check against X > 100. Otherwise, just pretend that id=123 isn't in the database.

Of course, this is a simple case, I expect that more complicated cases may not be solvable at all. Like I think the correct way is to say that certain (and perhaps all except the primary key) columns need authorization prior to access.

This is, I think, entirely a database implementation question, and ultimately has nothing to do with Zanzibar itself.

So to answer your question

> what good is it as a central authz service when you can't securely implement search on top of it?

You can, you just can't do it in the way you've described. Its a difficult problem that the central authz service shouldn't solve, and the design of this service is still faster than all of the others.