Access to objects is controlled via the system security routines.

These routines operate on security attributes. Security attributes apply to an object and control who has access to that object.

Security attribute strings have the form <id>=<acc>+<acc>+...,<id>=<acc>+<acc>+..., where <id> is an identifier number (you make up for uniqueness), and <acc> is a type of access to be granted to that identifier number (like look, read and write).

These routines operate on security keys. Security keys apply to an thread and control what the thread can access.

Security keys strings are just a comma separated list of identifier numbers.

These routines apply a set of keys to a set of attributes:

Now the design of these routines is such that they are the only ones that know about the contents of those strings, binary buffers and the objects themselves. So you could re-write just these routines if you wanted to have a simple uid/gid scheme instead of this more general acl paradigm.

All objects directly accessible to user mode have security attributes to control who can access them.

Threads have these additional security related structures: User blocks have this additional security related structure:

When a user logs in, the oz_util_logon.oz image is activated as part of the system process (it runs with full access to anything). It reads the user's username and password, then gets the user's security keys and attributes from the password file. Then it creates the user block with the security attributes and saves a copy of the security keys there too (as the authorized keys). Finally, it creates a job and spawn a process under that user block to run the cli, giving it the security keys, security attributes, and default creation security attributes from the password file.

A thread can change its (or any thread it has write access to) security keys, but it can't give it more than what is in the calling thread's user block's authorized keys.

A thread can change any security keys (of an object it has write access to) to anything it wants, it is just not advisable to change them to something that prohibits it from writing that object in the future, but it is possible this may be desirable in some situations.

By default, objects are created by the calling thread's default creation security attributes. If other attributes are desired, some objects have a routine to directly change the attributes. Most objects can also have their security attributes specified by placing (security_attributes) on the end of their name. Objects that support this are:

When the object is created, the (security_attributes) is stripped off the end of the name and parsed, then the object is created with the specified attributes. The (security_attributes) string does not become part of the object's name. So for example, you could tell the system to create file common.log(5=look+read+write,6=look+read+write), and the file would be named just common.log, and threads with either key 5 or 6 (or both) would be able to look at, read and write that file.