found that by instead defining a role by negative permissions i e those resources and or actions related thereto that are not permitted to subjects in that role the evolution of a system is more convenient to manage in this way the system is only required to track and update the denied resources for particular roles it has also been recognized that by defining a role in terms of negative permissions i e what subjects in that role cannot do malicious users can be thwarted from creating false user accounts since selecting functions associated with the resources takes permissions away rather than adds them application_number US 201113183947 A description in the acl_roles table are the 5 basic roles previously described in the acl_role_permissions we see that accountmanager servicemanager nonbillservicemanager and otaslmanager can perform all actions on their respective resource as indicated by the asterisk in the actions column the support role has some permissions denied against the u201c accountmanagement u201d resource and some explicitly granted for the u201c servicemanagement u201d resource the acl_roles_tree data depicts role extension the support role extends from the parent roles accountmanager nonbillservicemanager and otaslmanager in the acl_user_roles table the user u201c ganymede u201d is given the role u201c support u201d in the acl_user_permissions table the user u201c ganymede u201d has been explicitly denied the u201c activate u201d permission because of this user 39 s role membership u201c support u201d it was previously granted but a user with a higher authority level was able to deny it referring.