There are several problems here, mostly created by with the terminology we use in the object/privilege/permission system.
The privileges read/write/admin have no fixed meaning with regard to what can be done to a particular object. But they are hierarchical. Admin implies read/write.
However, additional privileges are difficult to maintain, they have to be granted individually, and the lead to an explosion in the size of internal mapping tables.
I would also wonder if using a privilege on a particular object to is really what you want to use when deciding to create a subobject.
In fact, this idea is only a little improved over Malte's suggestion to make acs object types into objects.
Here is the problem: privileges granted on a particular object, like read, write, admin apply to manipulation of that object. That is, the data in a row of the object types table. Otherwise you are making an exception of how object privileges are used. Turning object types into objects and assigning permissions on these objects is a complete abuse of the idea of permissions: they apply to the objects themselves (the type object).
The concept of proxy object and how it should be used in this case is confusing. I don't think I do a good job of explaining it. There are two parts.
First the rel_segment places a user in a particular segment of a group. A group is a party, a party can own things. A party is the 'container' you ultimately need for application data, but applications are complex, so you need a complex party: a group with segments of users, roles.
When you ask a role type question, you are looking at membership, not permissions. Membership is the container for the role, but it isn't a permission question.
Privileges on a particular object comes after you look at if and how a particular user can interact with objects of that type.
However for creating new objects which exist in a hierarchy, it is common to require either admin or write privilege on the context_id for the object, sometimes this is the same as a parent_id, but in any case, permission checks should be done for any object_ids used in an object. This is confusingly similar to a role, but has a completely different purpose.
One final distinction between privilege and role. If you do use 'create' on the parent object to imply the right to create children, then you are stuck wih the need for another type of create for each role. This is exactly what you don't want. It doesn't help the object/permission system to add privileges.
