Actually, I think this is absolutely inappropriate, but I might be missing the essential points that justify this design. My question therefore is:
Given that the corba rights family is intended to serve most cases, what exactly are the semantic connotations for these four rights? Are they simply chosen in an ad hoc way, or is there some deeper reasoning behind this choice, such as why it would make administration easier in some cases? If so, how and in which cases?''
This is a good question, and one which we discussed extensively during the initial definition of the specification. The basic motivation for defining a small, standard set of rights and strongly encouraging everyone to live with that set is that there are a potentially unlimited number of methods in any given CORBA system (each new class can introduce large numbers of them), and the set of methods is semantically very complicated from the viewpoint of the administrator - methods with the same name may do different things, methods with different names may do the same thing, methods may have names which do not at all suggest their function or sensitivity, and methods belonging to the same class may have very different consequences if invoked on different instances with different internal states. This makes it almost impossible for administrators to manage policy using methods. Rights are thus introduced as a way to "group" methods. We could have stopped after introducing the notion of rights, and allowed implementors or even administrators to define arbitrary collections of rights, but we felt that this would lead to a chaotic situation in which the population of rights would be widely variable across different vendors' implementations and different customers' or even departments' deployments, making training and interoperability a nightmare.
We chose instead to conceive of rights as a kind of language, to be used definers of new object classes to communicate the sensitivity of their classes' methods to the security administrator. We defined a small language of rights which corresponded generally to the KINDS of operations which an object-oriented system's methods perform, namely:
method reads and returns one of the object's data members method writes one of the object's data members method executes one of the object's member functions
We defined a right corresponding to each of these basic KINDS of operations, and added one more right to deal with the real-world fact that some operations of the same KIND are more sensitive than others of the same KIND.
Hence the intended semantic connotations of the rights in the "corba" family are:
Clearly they aren't an exact match for all possible security policies in a CORBA environment, but I don't think a system which supports an exact match for all possible policies would be one which could be administered by normal humans.