Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify the protocol #1

Open
DanielSank opened this issue Jan 11, 2016 · 6 comments
Open

Specify the protocol #1

DanielSank opened this issue Jan 11, 2016 · 6 comments
Assignees

Comments

@DanielSank
Copy link
Owner

This should probably happen before much more code is written.

@DanielSank DanielSank self-assigned this Jan 11, 2016
@lovesegfault
Copy link
Contributor

What options do we have for protocols? I see that you already added something that looks like protocol specifications at the beginning of cappy.py, is that what this is about?

@DanielSank
Copy link
Owner Author

Note that "object", "reference", and "capability" all sort of mean the same thing.

Suppose we're running a service for renting digital items from a store. I am the server and you are a client. When you log in, I send you a reference to the store. On this store reference you can call certain methods such as get_list_of_available_items which returns a list of references to available items for rent. The protocol is just a specification of how to communicate these references.

We'd essentially want to send something like a "class name" answering the question "what kind of object is this?" and then whatever data is needed to describe a particular instance of the object. For example, if there's a banana for rent, I might respond to your get_list_of_available_items call by sending you a message saying

Here is a reference to a "banana". Its color is "yellow" and its mass in grams is 120.

That message could be encoded in any number of ways. JSON is probably a good place to start since it's simple and well supported.

In your code you might have a look-up table in which the string "banana" maps to a Banana class which is then instanced to represent this banana, e.g. so that your client program can draw a picture of it on the shelf of the store.

A more complex feature would be if references can be passed as arguments to remote calls on other references. For example, the store might have buy_item. When you call this method, you might pass your banana reference as an argument. A nice feature of this strategy is that you can only buy items you've been given permission to buy (because I keep track of what references I've given you). That's one of the main features of capability style RPC: it helps you get security/correctness right.

@lovesegfault
Copy link
Contributor

Did you google for the average weight of a banana? Because you got the average weight of a banana perfectly right.
So we are now heading into OCM territory, let me see if I got this right. In an OCM-based system you get added security because the client will only 'know' what the server wants him to; had the server not passed the object/reference of banana to the client he wouldn't even know it existed, and thus would be unable to use it with any locally available methods.
Am I correct to think like this?

@DanielSank
Copy link
Owner Author

Did you google for the average weight of a banana? Because you got the average weight of a banana perfectly right.

Guilty as charged.

let me see if I got this right. In an OCM-based system you get added security because the client will only 'know' what the server wants him to; had the server not passed the object/reference of banana to the client he wouldn't even know it existed, and thus would be unable to use it with any locally available methods.

That's exactly right. One of the nice things about OCM is that security is easier to reason about. For example, even if you guess a capability's id I can look my table and see whether or not I ever gave you a reference to that capability; even if you successfully guess an id I gave to someone else, I automatically ignore your attempts to invoke methods on that capability.

Now, of course, security is never free. What does it even mean to talk about giving a capability to you versus someone else? In every implementation I've seen so far (which is only two), users are defined by their (TCP) connection. I don't know the security concerns with that: is it possible/hard to spoof someone else's connection? Still, that aside, the mere fact that I don't have to manually juggle access permissions is a huge win in my opinion.

@lovesegfault
Copy link
Contributor

Instantly in love with OCM, it just seems like such a well-thought and functional way to control permissions.

When you say users are defined by their TCP connection you mean as in their IP address? If so, than we could add some security by storing MAC/IP pairs.

@DanielSank
Copy link
Owner Author

When you say users are defined by their TCP connection you mean as in their IP address? If so, than we could add some security by storing MAC/IP pairs.

I confess ignorance. A piece of code that "opens a TCP socket" manages ports, IP address, etc. in ways that I do not pretend to understand (yet). I imagine that once one has established a secure connection using TLS (previously known as SSL) then this problem makes more sense. I think it's not worth worrying about this until we have established a messaging protocol and written a prototype. I started drafting the messaging protocol last night. Hopefully will have something worth discussing soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants