Should Users Be Processes

[Moved here from NameSpace]

People are most familiar with namespaces in filesystems. When programmers use the word NameSpace, they usually mean what a process sees when executing. Of course, this is a completely artificial distinction. A user is a process and, in a decent OS, vice versa. And the distinction between OS and language is also arbitrary since LanguagesAreOperatingSystems.

This would seem to preclude one user from having multiple processes, and one process from serving multiple users.

Well, that's completely wrong. A user IS An object, and an object IS A user. You do not have to create this relationship because it is already there. You merely have to recognize, accept, represent and reflect this relationship in any decent OS. This is what's not done.

What's wrong with having users and processes be two different sets, with relations between the two sets, as is universally done in all mature general purpose operating systems? What's the motivation for proclaiming an identity between users and processes?

Dealing with reality as it is, instead of how some programmer thinks it should be.

As a result of the failure of programmers to recognize that objects are users, we have insecure implementations of objects; AccessControlList instead of CapabilitySecurityModel. As a result of the failure of programmers to recognize that users are objects, we have self-inconsistent implementations of users; different environments for multiple logins of the same user.

This is all well and good, but could you give a concrete example? I find statements like "an object is a user" a bit disconcerting, first because this is obviously wrong (whereas "there exist objects which are|represent a user" seems less grandiose and a bit more correct), and second because I don't understand how you could implement a user "object" explicitly... any light for my tunnel? Thanks.

In any CapabilitySecurityModel, each object is a user with the exact same type of rights and capabilities as a "real" user. It can own capabilities to other objects. It can send messages to other objects. It can read, write, whatever other objects if it has the requisite capabilities to do so.

A human user is the result object of the login process. User objects are created by logins out of preexisting objects, by tying some form of input-output to a command processor to some point in the graph of objects. IOW, all you're doing is translating human commands to low-level object commands.

Remember the movie Tron? Processes never actually saw users, they merely saw commands coming from other processes.

Even if you don't have "every object is a user", it's still the case that every user is an object (a process) in the system. It's also the case that every process is a user. The only distinctions are that in broken systems, each process might not be a distinct user. And also that every object might not be a (notional) process.

A human user is not a software object; his/her interests are represented by a software object (in the capability systems we are referring to). It's fine to say that this is a "user object", but to speak as if the object and the human are the same thing is a LevelCategoryError. TheMapIsNotTheTerritory.

And yes, there are important technical differences in how typical ACL and capability systems model users and objects. Making this category error just obscures the technical differences. -- DavidSarahHopwood