User Domain

User domains are a common SecurityPattern enabling users to possess objects yet be able to share them to the precise extent they wish.

What is a user domain? It's the set of objects over which they have total control. If a system obeys NameSpace ideals (eg. SmalltalkLanguage) then this is the subgraph of objects directly beneath the user. Note that an object can belong to more than one user domain. That is, user domains can overlap.

The proper way to structure user domains is to not structure them at all. A user domain is represented by the top-level object in the subgraph. This object already "belongs to" another object, which belongs to another object and so on, which ultimately belongs to one or more users, who are seen as the first user's administrators. IOW, the graph already provides all of the structure required ... IF it contains no cycles.

Why? Because if two users have total control over each other, then each has the power to dissociate themselves from the other, while retaining total control over the other. Such a situation is inherently unstable and totally unpredictable.

But since cycles are already ruled out for other reasons, or they are simply too expensive to detect, the instability of having cyclic user domains doesn't add anything to the equation. Either it's not a problem, or you just have to put up with it anyway.

Why are cycles ruled out for other reasons?

You know, I can't recall what I meant ... unless I was thinking of the NestedProcess? structure being reflected in TheObjectGraph? Because all components are singly-rooted and processes are organized in a tree structure, but that doesn't reflect. Or maybe I was thinking that there is no legitimate need for cycles so users won't make them, but that's dubious. I think it was due to a misunderstanding of link generation.

Some more points:

User objects are in no way special to the system. They're just the children of a login process, that's it. So user domains are in no way different from object domains. It's useful for the class browser to distinguish users from other objects, perhaps by their name (eg. "user John") but anything more than this is really just asking for totalitarian control of the system by a privileged elite. If user John decides to administer users Jane and Henry (by providing a login process of his own, accessible from his own login process), that's really not the business of the higher-ups.

It must be possible for a user to aggregate objects, and to aggregate the same objects in multiple ways. That's what the no_perms flag in PermissionFlags is for. A system which does not allow such aggregation, such as Unix, is quite simply an insane heap of junk.

Of course, any SecurityComplete? CapabilitySecurityModel is able to provide this. The only question is whether they provide it easily.

I don't see any particular difficulty. KeyKos supported something similar.

Moved from NameSpace, the following represents some early thought about user domains:

Domains are local because they don't need to intersect, and public objects in the world can be attached to your domain either by making your domain their subdomain (highly undesirable) or by adding a neutral "undirected" link from your domain to that object. And yet, so long as there is a sequence of willing users/objects in between them, any two people who wish it can connect their domains together. A user steps outside of their domain and subject to link permissions the moment they traverse a link in the "upwards" direction. -- RichardKulisz

CategorySecurity CategoryOperatingSystem