Chris Mellon

Just here so I have a WikiName to refer to myself by. I'm new.

Welcome to Wiki.

Thanks for your WxWidgets comments. You know, the ambiguity in the word "hard" is interesting. It can mean "conceptually easy but time consuming", or it can mean "conceptually difficult but easy once you get the idea", or it can mean both or neither.

I think that, psychologically, most things seem conceptually easy once you understand them thoroughly, which means that, with sufficient background, most kinds of programming are "easy but tedious", in one sense. But there still remains the sense of easy versus hard relative to e.g. how long it takes to do something.

Good to keep in mind in future discussions. -- DougMerritt

What page was it where we ended up talking about stateful high-level caps? Anyways, you asked so here's my design of a universal system of Power Relations. I'll be interested to know what you can make out of it, specifically whether you can see how it can be used to do stuff, alternative concepts, and why the alternatives aren't as good.

Objects are Linked to each other with certain Powers over each other. The links form a directed singly-rooted Graph with vertex directions set by Ownership.

Ownership is a transitive relation between objects which supercedes all other powers over an object; an owner has all powers. An owner gets to specify powers.

The Standard Powers are accessing, modifying, reflecting and owning.

Links route Messages to their destination in the graph. Messages pick up powers according to the links they traverse.

Am I correct in understanding that you mean Message here in the Smalltalk sense? IE, a request for an object to perform an action?

At any time, links can Allow, Deny or react to any power they choose to invent.

Links can choose to neither allow nor deny a power but rather to Inherit the choice made by the previous link in the Message Path. This supports Aggregation. The best default set of powers in most cases is "neither allow not deny".

Any modification uses up an object's Resources. An object can request to acquire resources from its links. Links transfer or deny requests based on their Quota. The best default quota in most cases is Infinite.

An object can grow in size by acquiring more of some Positive resource. It can shrink in size if it has an Open Path to the Infinite Source of a corresponding Negative resource.

An object keeps track of all its Versions. Revoking a power only applies to Future Versions. The past cannot be revoked.

The past can be accessed and modified in the same way as the present. When the past is modified, it branches off a new universe. Time travel works!

I think that's all of it, but either way it's 10 lines. Good luck trying to implement it. Though you shouldn't bother because I already have. I just have to sink this into some kind of OO programming language.

-- RK

I see how you can use this to implement conventional ACL style permissions. I assume grow/reduce in "size" can mean any sort of increased/reduced consumption, so you can use that to model process priority/memory usage as well as the more obvious file size quotas. And you can recursively apply it to itself in order to secure the managment of security. I like that Objects have resources that they share via Links. A File might be 32mb in size, and need to grow, so it requests some resources from the User who asked it to grow. The User might not have any more "disk space" quota left, so it would request some from another, higher level object (perhaps theres a Disk object that represents all the un-used disk space?). If there's none from there it might cannibalize it from another User or File that it has Ownership over. The problem I see with this (and I've read your views that resource starvation is a permissions issue) is that it puts the burden of avoiding resource starvation on the User.
- It`s actually worse than that since there's the whole class of correctly reallocating resources that I avoid by the simple expedient of not allowing reallocation. Resources you commit are committed forever so long as someone to whom you once gave permission to use the object still uses it.
- What do you mean by "you can recursively apply it to itself in order to secure the management of security"? Power relations is a total system of security, there is no security beyond it. However, there are derivatives and securities which are a different thing.
As you describe it, I think you'd still end up with a root "Owner" who has total control over everything. Am I misunderstanding some of the implications, or is this intentional? I thought the idea of root was in disfavor amongs security theorists.
- Not in a distributed system. Each machine has a single root which merely represents practical realities such as that the processes are all under the control of the memory. Even if you defined the memory manager as not to have access to the root node, this would just be stupid because the memory manager can always cheat.
- There are several further considerations at work. The first is that the root need not be a human or even a normal process. Yes, there is a root node in the machine's graph, this doesn't mean that any normal process (other than the memory manager) has access to it. And users are a subclass of normal processes so no human root need be necessary. The second consideration is that the "no root" idea is the stuff of ACLs. The third consideration is that the root user need not be a human user, it can be an automated vote-tallying robot.
Why should reducing size require permissions? Is it just to keep everything symmetrical (perfectly valid reason, I hasten to add), or is there a more specific/practical reason I'm missing?
- Because many, many components of an OS have objects which are fixed-size and if you can't express "you can't reduce the size of this object" in terms of power relations then it means you'll have to cheat. And cheating is bad. Examples of such components are, the HD's blocks, the Logger's logs, the memory manager's pages, et cetera.
- Also, even at the highest levels of the storage stack, it's often desirable to give someone the ability to add objects but not remove any. An email queue for example. Unfortunately, I had a lot of problems finding a model where users could add objects without overwriting what was already there and eventually I decided that a consistent model with this property didn't exist. I did come up with a workaround but I'd have to look up my notes to figure out what it was. Even this much detail is based on my faulty memory.
One thing that strikes a wrong chord with me is that objects are responsible for examining the powers on messages themselves, and performing or not performing the action requested. I don't know why this bugs me so much, because as I explore it further it's consistent and I don't even see a flaw, but something about it just tells me it's wrong.
- There are implementation problems. Sometimes you need information in the links that's only available in the objects. I don't know off-hand how I resolved them, I'm only 80% sure I did.
I don't see the benefit in having the past be changeable. It seems to open up a whole slew of potential problems - if an object denies your message, just send it to older and older versions of the object until you get one that permits it. I suppose you've got the potential for reversible computing, but the theoretical as well as the practical limitations of that are pretty high. Maybe if you had one of the fancy reversible CPUs that have been theorized (reversible computations mean no data is lost, means no entropy, means no waste heat(!). This is just barely at the edge of my understanding).
- Actually, it has nothing to do with reversibility. It has to do with monads as I barely understand them from OnMonads and what MichaelSparks told me.
- You can't send a message to an older version of an object except by going through caps. So to send it to an older version, you have to have had a cap to that object when it was that version and have had powers at the time.
- The benefit of doing this is that you can fork reality with zero effort and minimal cost. If someone tries to screw everyone else unilaterally, they can just undo it and work in a different reality from the SOB. There are issues with mutual transparence and also resource exchange (especially with the commitment problems I've outlined above) between the realities.
There's some interesting implications for addressing/routing that I haven't quite fully assimilated yet. I wonder if a model of routers/firewalls would be useful to implementing/understanding this? A message can only be sent to an object via a Link (otherwise, it'd have no Powers when it arrived). That means that you need some way of tracing along Links to eventually arrive at the destination. The more I try to understand this, the more I think that network routing is exactly what we're talking about here. If you actually do it this way, you get distributed computing for free, which is nice.
- Depends what you mean by distributed computing. If it's that processes can have parts spread across many different computers, then yes. OTOH, I made sure this ability was build in from the start and I had to work hard on scheduler / mem manager designs that allowed this to happen. So I don't think it follows automatically from having a capability model. Distribution at a coarser level, where you see objects on other machines the same way you do those on yours, does come free. Distribution at a finer level, where multiple machines are seen like a single machine is actually a higher-level abstraction.
Is it acceptable for a Link to simply drop a message entirely, rather than setting specific powers?
- Yes and no. If the link doesn't permit accessing and the message requires further routing then the message is dropped / returned with a permission missing exception. If you mean dropping a message for some arbitrary reason then no.
Re-read a little more, not sure what you're meaning by Open Link. I though Links set powers, so the target object has to examine the powers on the Message before responding. The term Open Link implies to me that the link chooses to allow or deny the message itself, which is more like the traditional ACL model (or the firewalling routers). Maybe it's both?
- Actually, the term is Open Path. Open Links are the model for owners having access to future versions of an object. But an Open Path is just a path of links none of which blocks a resource acquisition request.
- There's two concepts are work. Messages go forward through links and they have a predetermined path through the graph. Once the message hits an object, the object may send an acquisition request backwards through all links and all paths. If a user wants to send resources forward to an object, then they do so ahead of time. Fortunately this is handled automatically by in the HCI stack by the ObjectBrowser so human users don't need to do this.

Chris, are you deleting RA's comments on IvanIllich and elsewhere? -- RK

CategoryHomePage