Live data from Hacker News

Zanzibar: Consistent, Global Authorization System

ai.google

91–100 of 137 posts

Re: Zanzibar: Consistent, Global Authorization System

#91
post #88

Earlier quoted context omitted.

Colossus is their data center scale filesystem. They dont talk about it..

Colossus is actually the only project I can think of for which they had one of the leaders sit down with Kirk McKusick and have a chat for ACM Queue, instead of a paper. https://queue.acm.org/detail.cfm?id=1594206

And they reveal exactly zero details. I know a bit about it, but not enough to say exactly what semantics it offers to file system clients. I believe it is not POSIX-like, hence the need to layer Spanner and GCS over it.

Re: Zanzibar: Consistent, Global Authorization System

#92
Not sure how I feel about adopting a countries name for a project.

Or more to the point I'm not sure how I would feel if every time I searched my countries name on the web this Google project appears rather than my actual country.

i.e Zanzibar is a national identity not just a "spice" island

Re: Zanzibar: Consistent, Global Authorization System

#93
post #88

Earlier quoted context omitted.

Colossus is actually the only project I can think of for which they had one of the leaders sit down with Kirk McKusick and have a chat for ACM Queue, instead of a paper. https://queue.acm.org/detail.cfm?id=1594206

And they reveal exactly zero details. I know a bit about it, but not enough to say exactly what semantics it offers to file system clients. I believe it is not POSIX-like, hence the need to layer Spanner and GCS over it.

There's been a teensy bit more details than that, e.g. [1]. If you think about exactly the file semantics that Bigtable would require (append, pread) that's exactly what is provided. Note that Colossus and D are two separate things. Google systems can use D without Colossus and a long time ago people used Colossus without D, although today Colossus/D is implied. The presentation gives the broad strokes of how Colossus is able to bootstrap itself from Chubby. It helps if you've also read the Bigtable paper [2].

1: http://www.pdsw.org/pdsw-discs17/slides/PDSW-DISCS-Google-Ke... 2: https://static.googleusercontent.com/media/research.google.c...

Re: Zanzibar: Consistent, Global Authorization System

#94
Excellent paper. As someone who has worked with filesystems and ACLs, but never touched Spanner before, I have some questions for any Googler who has played with Zanzibar. (in part because full-on client systems examples are limited)

A check my understanding: Zanzibar is being optimized to handle zookies that are a bit stale (say 10s) old. In this case, the indexing systems (such as Leapord) can be used to vastly accelerate query evaluation.

Questions I have (possibly missed explanations in the paper):

1. If I understand the zookie time (call it T) evaluation correctly, access questions for a given user are effectively "did a user have access to a document at or after T"? How in practice is this done with a check() API? The client/Zanzibar can certainly use the snapshots/indexes to give a True answer, but if the snapshot evaluation is false, is live data used (and if so by the client or Zanzibar itself?)? (e.g. how is the case handled of a user U just gaining access to a group G that is a member of some resource R?)

2. Related to #1, when is a user actually guaranteed to lose access to a document (at a version they previously had access to?) E.g. if a user has access to document D via group G and user is evicted from G, the protocol seems to inherently allow user to forever access D unless D is updated. In practice, is there some system (or application control) that will eventually block U from accessing D?

3. Is check latency going to be very high for documents that are being modified in real time (so zookie time is approximately now or close to now) that have complex group structures? (e.g. a document nested 6 levels deep in a folder where I have access to the folder via a group)? That is, there's nothing Zanzibar can do but "pointer chase", resulting in a large number of serial ACL checks?

4. How do clients consistently update ACLs alongside their "reverse edges"? For instance, the Zanzibar API allows me to view the members of a group (READ), but how do I consistently view which groups a user is a member of? (Leapord can cache this, but I'm not sure if this is available to clients and regardless it doesn't seem to be able to answer the question for "now" - only for a time earlier than indexed time).

Or for a more simple example, if I drag a document into a folder, how is the Zanzibar entry that D is a child of F made consistent with F's views of its children?

E.g. can you do a distributed transaction with ACL changes and client data stored in spanner?

5. It looks like the Watch API is effectively pushing updates whenever the READ(obj) would change, not the EXPAND(object). Is this correct? How are EXPAND() changes tracked by clients? Is this even possible? (e.g. if G is a member of some resource R and U is added to G, how can a client determine U now has access to R?)

Re: Zanzibar: Consistent, Global Authorization System

#95

Earlier quoted context omitted.

The most impressive part about Google is how its emphasis on internal standards has allowed it to build some really impressive stuff. Eg, You can do a sql join on any dataset, in any datacenter. You can turn any query into a hosted visualization. Every test invocation is streamed to a central server and results can be shared with a url. There’s more, but those are my two favorites.

Is the join a Spanner query, or is there a system on top of a Spanner that federates/aggregates databases?

Most of adhoc analysis don’t even need Spanner. With Dremel, you can simply define a table on bunch of sharded files and do a SQL query on them.

Re: Zanzibar: Consistent, Global Authorization System

#96
post #74
post #60

Earlier quoted context omitted.

Throwing servers at the problem is less impressive then thinking very hard and solving it with less.

It's not servers. It's who will have the best submarine cables. A game in which Apple is not participating btw. Not even with an Elon style moon, err, low earth orbit shot. https://blog.apnic.net/2019/04/03/the-future-of-undersea-int...

Apple has no need for undersea cables.

It doesn't matter if iCloud is slow or not since most of the interactions with it are in the background. And all of it's content e.g. App Store or Apple Music are cached by CDNs which are hosted in pretty much every country.

Re: Zanzibar: Consistent, Global Authorization System

#98
post #88

Earlier quoted context omitted.

Colossus is actually the only project I can think of for which they had one of the leaders sit down with Kirk McKusick and have a chat for ACM Queue, instead of a paper. https://queue.acm.org/detail.cfm?id=1594206

And they reveal exactly zero details. I know a bit about it, but not enough to say exactly what semantics it offers to file system clients. I believe it is not POSIX-like, hence the need to layer Spanner and GCS over it.

??? The original GFS paper, which the chat references repeatedly, was clear about the semantics not being POSIX-like. The interview mentions that, too, along with stuff like snapshots. Colossus is basically the same, with increased scalability.

Re: Zanzibar: Consistent, Global Authorization System

#99

What's interesting to me here is not the ACL thing, it's how in a way 'straight forward' this all seems to be. It's the large architecture of a fairly basic system, done I supposed 'professionally'. I'm curious to know how this works organizationally. What kind of architects involved because this system would have to interact with any number of others, so how do they do requirements gathering? Do they just 'have expe…

The system is actually pretty complicated and nonobvious once you consider its caching layers, heavy reliance on spanner, assumption that ACL read times can be stale, and the various assumptions and limitations in the namespace controls.

The underlying model of role based access control (and viewing groups as just other resources with ACLs) is already well known.

Re: Zanzibar: Consistent, Global Authorization System

#100

Earlier quoted context omitted.

This is absolutely incredible. Since we saw login with Apple yesterday, makes me wonder if any of the other big companies can compete with this. Curious about Facebook/Netflix/Amazon. Netflix seems zippy, but I've never looked at the request timings, which could differ pretty dramatically from UI load times. I imagine Google also dwarfs their login scale. Would be interesting to see numbers capturing full load time f…

This isn't a login service, this is an ACL service. Related space, but different concerns. You wouldn't send a user's password here to find out if it's correct (authentication), you'd use this to figure out if a user can do something once you know who they are (authorization) :) Also, generating the login page etc is often more expensive than the actual 'validate the username and password'. Getting to the server is a…

Awkward. I realized it was used for authz, but for some reason I assumed it would be used for authn as well. Now I’m wondering how Google does authn...

And yeah, the second half of my comment is trying to scope down the comparison to one that is reasonably “fair”

Post reply on HN