JavaScript is not currently enabled, but is required for full
CodeSonar manual search and browse functionality.
If you are viewing this file in your hub's Web GUI, enable
JavaScript in your browser: you will also need it for GUI
functionality.
If you opened this file directly from disk, your browser may be
directly suppressing JavaScript functionality: certain browsers
perform this suppression on local files (but not files delivered by
web servers) for security reasons.
-
If you access the manual through the hub's Web GUI, the
functionality will not be suppressed because the hub is a web
server.
-
Alternatively, your browser may allow you to explicitly
disable the security setting that suppresses functionality. See
the CodeSonar
FAQ for more information.
RBAC: Role-Permissions
For global
permissions, which do not apply to specific resources, a
role-permission is a single rule assigning one G_* permission to one
role.
In all other cases a role-permission is a single rule assigning
one resource
permission to one role
for one resource. The
permission must be applicable to the
resource.
The set of role-permissions for a particular role is determined as follows.
It is entirely possible for a role to hold the same
role-permission both directly and indirectly, and to hold the same
indirect role-permission through both role-inheritance and
resource-inheritance.
Roles with one or more parents have a (possibly empty) set of
role-inherited role-permissions, consisting of all global
permissions and resource-permissions that are directly or indirectly
assigned to at least one of those parents. (That is, all global permissions
and resource-permissions
that are directly assigned to at least one of the role's ancestor
roles.)
When a role holds some resource-permission
for a hierarchical
resource R, resource-inherited role-permissions grant the
same permission to the same role for each resource S that is directly
or transitively contained by R, provided that the permission is
applicable for
S.
For example, suppose the Engineer role is explicitly assigned
ANALYSIS_OWN_WARNINGS permission for some
project P. Then the Engineer role will also have resource-inherited
ANALYSIS_OWN_WARNINGS permission for
all analyses of P.
A resource-inherited role-permissions can only apply to a resource
if:
When you create a new securable resource, initial
role-permission settings related to that for that resource will
depend on the resource type.
| Resource Type |
Behavior |
Example |
independent
resource types:
Named Search
Report Template
Saved Chart
Role
Warning Processor |
Suppose a new independent resource X is created by a user
whose default
role is R. Then a new set of direct role-permissions are created so
that R has all applicable
permissions for X. |
If a user whose default role is Developer creates a new named
search, CodeSonar will create a new set of direct
role-permissions to give the Developer role all NAMEDSEARCH_* permissions for that search. |
hierarchical
resource types: Launch Daemon
Launchd Group
Analysis
Project
Project Tree |
Suppose a new hierarchical resource X is created under parent
resource Y. Then all direct and indirect role-permissions for Y
that are applicable to X are
now resource-inherited
role-permissions for X. |
If a user creates a new project P in project tree 1, all
PROJECT_*, and ANALYSIS_* role-permissions for project tree 1
are now resource-inherited role-permissions for P. |
The following table shows the default permissions assigned to each
of the built-in
roles when you start a new hub.
The resource role-permissions described here are for resources that exist at the time the hub is
created. Role-permissions for all subsequent resources are
determined as described in Initial
Role-Permissions for New Resources, above.
Some of these default role-permissions are immutable: they
cannot be removed from the corresponding roles. These immutable
instances are noted in the entry for each role; the remaining default
role-permissions are mutable, as are any other role-permissions
subsequently assigned to the roles.
| Role |
Default Permissions
(see note) |
|---|
| Administrator | The global, root project tree, and root launchd group
permissions listed below are immutable for the Administrator role. The permissions for
named seaches and other independent resources are mutable.
| Global |
G_ADD_WPROCESSOR,
G_ADMINISTER_CONTENT_SETTINGS,
G_ADMINISTER_HTTP_SETTINGS,
G_ADMINISTER_SMTP_SETTINGS,
G_ADMINISTER_USERS,
G_ANNOTATION_EXPORT,
G_ANNOTATION_IMPORT,
G_CHANGE_OWN_CERTIFICATES,
G_CHANGE_OWN_EMAIL,
G_CHANGE_OWN_EMAIL_ALERTS,
G_CHANGE_OWN_PASSWORD,
G_CREATE_USER,
G_FINDING_ADD,
G_FINDING_DELETE,
G_HUB_BACKUP,
G_HUB_DEBUG,
G_HUB_INFO,
G_HUB_LOGS,
G_HUB_METADATA,
G_HUB_SHUTDOWN,
G_HUB_VACUUM,
G_LICENSE_READ,
G_LICENSE_UTILIZATION_READ,
G_LICENSE_WRITE,
G_LIST_PROPERTIES,
G_LIST_USERS,
G_MANAGE_USERS,
G_PRIORITY_ADD,
G_PRIORITY_DELETE,
G_RECOVER_OWN_PASSWORD,
G_SIGN_IN,
G_SIGN_IN_CERTIFICATE,
G_SIGN_IN_PASSWORD,
G_SQL_CONSOLE,
G_STATE_ADD,
G_STATE_DELETE |
Project trees
(root project tree) |
ANALYSIS_ADMINISTER,
ANALYSIS_CONSOLE,
ANALYSIS_DEBUG,
ANALYSIS_DELETE,
ANALYSIS_EXISTS,
ANALYSIS_IR_QUERY,
ANALYSIS_READ,
ANALYSIS_TERMINATE,
ANALYSIS_WARNING_EXISTS,
ANALYSIS_WARNING_READ,
ANALYSIS_WRITE,
PROJECT_ADD_CHILD,
PROJECT_ADMINISTER,
PROJECT_DELETE,
PROJECT_EXISTS,
PROJECT_READ,
PROJECT_WRITE,
PTREE_ADD_CHILD,
PTREE_ADMINISTER,
PTREE_DELETE,
PTREE_EXISTS,
PTREE_READ,
PTREE_WRITE |
Launchd groups
(root launchd group) |
LAUNCHDGROUP_ADD_CHILD,
LAUNCHDGROUP_ADMINISTER,
LAUNCHDGROUP_DELETE,
LAUNCHDGROUP_EXISTS,
LAUNCHDGROUP_READ,
LAUNCHDGROUP_WRITE,
LAUNCHD_ADMINISTER,
LAUNCHD_DELETE,
LAUNCHD_EXISTS,
LAUNCHD_READ,
LAUNCHD_START_MASTER,
LAUNCHD_START_SLAVE,
LAUNCHD_WRITE |
Named searches
(every existing named search) |
NAMEDSEARCH_ADMINISTER,
NAMEDSEARCH_DELETE,
NAMEDSEARCH_EXISTS,
NAMEDSEARCH_READ,
NAMEDSEARCH_WRITE |
| Other independent resources |
REPORTTEMPLATE_ADMINISTER,
REPORTTEMPLATE_DELETE,
REPORTTEMPLATE_EXISTS,
REPORTTEMPLATE_READ,
REPORTTEMPLATE_WRITE,
ROLE_ADMINISTER,
ROLE_ASSIGN,
ROLE_DELETE,
ROLE_EXISTS,
ROLE_READ,
ROLE_WRITE,
SAVEDCHART_ADMINISTER,
SAVEDCHART_DELETE,
SAVEDCHART_EXISTS,
SAVEDCHART_READ,
SAVEDCHART_WRITE,
WPROCESSOR_ADMINISTER,
WPROCESSOR_DELETE,
WPROCESSOR_EXECUTE,
WPROCESSOR_EXISTS,
WPROCESSOR_READ,
WPROCESSOR_WRITE |
Administrator
has the same set of default permissions regardless of
whether or not the hub is created with the -permissive option.
|
| Anyone | All permissions for the Anyone role are mutable,
except that the named search permissions are
immutable for the saved searches named "all"
(there is one in each search domain).
Mutable role-permissions marked with * will be removed
if you click the Restrict Permissions button in the Security Dashboard. When the hub is created with the
-permissive option, Anyone has a broader set
of default permissions:
| Global |
*G_ANNOTATION_EXPORT,
*G_CREATE_USER,
G_HUB_METADATA,
*G_LICENSE_READ,
*G_LICENSE_UTILIZATION_READ,
*G_LIST_PROPERTIES,
*G_LIST_USERS |
Project trees
(root project tree) |
*ANALYSIS_CONSOLE,
*ANALYSIS_DEBUG,
*ANALYSIS_EXISTS,
*ANALYSIS_IR_QUERY,
*ANALYSIS_READ,
*ANALYSIS_TERMINATE,
*ANALYSIS_WARNING_EXISTS,
*ANALYSIS_WARNING_READ,
*PROJECT_ADD_CHILD,
*PROJECT_EXISTS,
*PROJECT_READ,
*PTREE_ADD_CHILD,
*PTREE_EXISTS,
*PTREE_READ |
Launchd groups
(root launchd group) |
*LAUNCHDGROUP_ADD_CHILD,
*LAUNCHDGROUP_EXISTS,
*LAUNCHDGROUP_READ,
*LAUNCHD_EXISTS,
*LAUNCHD_READ,
*LAUNCHD_START_MASTER,
*LAUNCHD_START_SLAVE |
Named searches
(every existing named search) |
*NAMEDSEARCH_EXISTS,
*NAMEDSEARCH_READ |
| Other independent resources |
*REPORTTEMPLATE_EXISTS,
*REPORTTEMPLATE_READ,
*SAVEDCHART_EXISTS,
*SAVEDCHART_READ,
*WPROCESSOR_EXISTS |
|
| Enabled | Global permission G_SIGN_IN is
immutable for the Enabled role.
Enabled
has the same set of default permissions regardless of
whether or not the hub is created with the -permissive option.
|
| Manager | All permissions for the Manager role are mutable.
The default ROLE_* permissions
listed below apply to all previously-existing roles
except the special Administrator role: by default, Manager only has ROLE_READ and ROLE_EXISTS for Administrator.
| Global |
G_ADMINISTER_CONTENT_SETTINGS,
G_ANNOTATION_EXPORT,
G_ANNOTATION_IMPORT,
G_CHANGE_OWN_CERTIFICATES,
G_CHANGE_OWN_EMAIL,
G_CHANGE_OWN_EMAIL_ALERTS,
G_CHANGE_OWN_PASSWORD,
G_CREATE_USER,
G_FINDING_ADD,
G_FINDING_DELETE,
G_HUB_METADATA,
G_LICENSE_READ,
G_LICENSE_UTILIZATION_READ,
G_LIST_PROPERTIES,
G_LIST_USERS,
G_MANAGE_USERS,
G_PRIORITY_ADD,
G_PRIORITY_DELETE,
G_RECOVER_OWN_PASSWORD,
G_SIGN_IN_CERTIFICATE,
G_SIGN_IN_PASSWORD,
G_STATE_ADD,
G_STATE_DELETE |
Project trees
(root project tree) |
ANALYSIS_ADMINISTER,
ANALYSIS_CONSOLE,
ANALYSIS_DEBUG,
ANALYSIS_DELETE,
ANALYSIS_EXISTS,
ANALYSIS_IR_QUERY,
ANALYSIS_READ,
ANALYSIS_TERMINATE,
ANALYSIS_WARNING_EXISTS,
ANALYSIS_WARNING_READ,
ANALYSIS_WRITE,
PROJECT_ADD_CHILD,
PROJECT_ADMINISTER,
PROJECT_DELETE,
PROJECT_EXISTS,
PROJECT_READ,
PROJECT_WRITE,
PTREE_ADD_CHILD,
PTREE_ADMINISTER,
PTREE_DELETE,
PTREE_EXISTS,
PTREE_READ,
PTREE_WRITE |
Launchd groups
(root launchd group) |
LAUNCHDGROUP_ADD_CHILD,
LAUNCHDGROUP_ADMINISTER,
LAUNCHDGROUP_DELETE,
LAUNCHDGROUP_EXISTS,
LAUNCHDGROUP_READ,
LAUNCHDGROUP_WRITE,
LAUNCHD_ADMINISTER,
LAUNCHD_DELETE,
LAUNCHD_EXISTS,
LAUNCHD_READ,
LAUNCHD_START_MASTER,
LAUNCHD_START_SLAVE,
LAUNCHD_WRITE |
Named searches
(every existing named search) |
NAMEDSEARCH_ADMINISTER,
NAMEDSEARCH_DELETE,
NAMEDSEARCH_EXISTS,
NAMEDSEARCH_READ,
NAMEDSEARCH_WRITE |
Other independent resources
(note: cannot modify roles for Administrator) |
REPORTTEMPLATE_ADMINISTER,
REPORTTEMPLATE_DELETE,
REPORTTEMPLATE_EXISTS,
REPORTTEMPLATE_READ,
REPORTTEMPLATE_WRITE,
ROLE_ADMINISTER,
ROLE_ASSIGN,
ROLE_DELETE,
ROLE_EXISTS,
ROLE_READ,
ROLE_WRITE,
SAVEDCHART_ADMINISTER,
SAVEDCHART_DELETE,
SAVEDCHART_EXISTS,
SAVEDCHART_READ,
SAVEDCHART_WRITE,
WPROCESSOR_ADMINISTER,
WPROCESSOR_DELETE,
WPROCESSOR_EXECUTE,
WPROCESSOR_EXISTS,
WPROCESSOR_READ,
WPROCESSOR_WRITE |
Manager
has the same set of default permissions regardless of
whether or not the hub is created with the -permissive option.
|
| User | All permissions for the User role are mutable.
Mutable role-permissions marked with * will be removed
if you click the Restrict Permissions button in the Security Dashboard.
| Global |
G_ANNOTATION_EXPORT,
*G_ANNOTATION_IMPORT,
G_CHANGE_OWN_CERTIFICATES,
G_CHANGE_OWN_EMAIL,
G_CHANGE_OWN_EMAIL_ALERTS,
G_CHANGE_OWN_PASSWORD,
G_CREATE_USER,
G_FINDING_ADD,
G_HUB_METADATA,
G_LICENSE_READ,
G_LICENSE_UTILIZATION_READ,
G_LIST_PROPERTIES,
G_LIST_USERS,
G_PRIORITY_ADD,
G_RECOVER_OWN_PASSWORD,
G_SIGN_IN_CERTIFICATE,
G_SIGN_IN_PASSWORD,
G_STATE_ADD |
Project trees
(root project tree) |
*ANALYSIS_ANNOTATE,
ANALYSIS_CONSOLE,
ANALYSIS_DEBUG,
*ANALYSIS_DELETE,
ANALYSIS_EXISTS,
ANALYSIS_IR_QUERY,
*ANALYSIS_OWN_WARNINGS,
ANALYSIS_READ,
ANALYSIS_TERMINATE,
ANALYSIS_WARNING_EXISTS,
ANALYSIS_WARNING_READ,
*ANALYSIS_WRITE,
PROJECT_ADD_CHILD,
*PROJECT_DELETE,
PROJECT_EXISTS,
PROJECT_READ,
*PROJECT_WRITE,
PTREE_ADD_CHILD,
*PTREE_DELETE,
PTREE_EXISTS,
PTREE_READ,
*PTREE_WRITE |
Launchd groups
(root launchd group) |
LAUNCHDGROUP_ADD_CHILD,
*LAUNCHDGROUP_DELETE,
LAUNCHDGROUP_EXISTS,
LAUNCHDGROUP_READ,
*LAUNCHDGROUP_WRITE,
*LAUNCHD_DELETE,
LAUNCHD_EXISTS,
LAUNCHD_READ,
LAUNCHD_START_MASTER,
LAUNCHD_START_SLAVE,
*LAUNCHD_WRITE |
Named searches
(every existing named search) |
NAMEDSEARCH_DELETE,
NAMEDSEARCH_EXISTS,
NAMEDSEARCH_READ,
NAMEDSEARCH_WRITE |
| Other independent resources |
REPORTTEMPLATE_DELETE,
REPORTTEMPLATE_EXISTS,
REPORTTEMPLATE_READ,
REPORTTEMPLATE_WRITE,
SAVEDCHART_DELETE,
SAVEDCHART_EXISTS,
SAVEDCHART_READ,
SAVEDCHART_WRITE,
WPROCESSOR_EXECUTE,
WPROCESSOR_EXISTS,
WPROCESSOR_READ |
User
has the same set of default permissions regardless of
whether or not the hub is created with the -permissive option.
|
The default permissions in the table above will be assigned as
follows.
- Each role is directly assigned each of the global permissions
listed in its row of the table.
- Each role is directly assigned a set of resource
role-permissions based on the permissions listed in its row of the
table.
- The root project tree permissions are
applied to the root project
tree. This is the only project tree on a new hub.
The role's root project tree permissions will contribute to
the resource-inherited
role-permissions sets for all other project trees,
projects, and analyses on the hub.
- The root launchd group permissions
are applied to the root launchd
group. This is the only launchd group on a new hub.
The role's root launchd group permissions will contribute
to the resource-inherited
role-permissions sets for all other launchd groups and
launch daemons on the hub.
- The named search permissions are
applied to each of the named searches that exist on the hub at
creation/upgrade time.
- A new hub contains no securable saved charts, report
templates, or warning processors. (Predefined report templates
and chart shortcuts are not
securable.)
CodeSonar will adjust the role-based permission assignments for a
user in the following special cases.
These special cases are discussed below.
Special user Anonymous is always
treated as if it does not have certain permissions, even if its
assigned roles would otherwise confer those permissions. This means
that users in anonymous sessions
are always treated as if they do not have these permissions.
The relevant permissions are listed below. Note that the resource-permissions
on the list cannot be held by Anonymous for any resource.
|
G_*: Global Permissions
|
G_CHANGE_OWN_PASSWORD, G_CHANGE_OWN_EMAIL, G_CHANGE_OWN_EMAIL_ALERTS, G_RECOVER_OWN_PASSWORD, G_SIGN_IN_PASSWORD, G_ADMINISTER_USERS, G_ADMINISTER_HTTP_SETTINGS, G_ADMINISTER_SMTP_SETTINGS, G_ADMINISTER_CONTENT_SETTINGS, G_ADD_WPROCESSOR, G_ANNOTATION_IMPORT, G_SIGN_IN_CERTIFICATE, G_CHANGE_OWN_CERTIFICATES, G_MANAGE_USERS |
|
ANALYSIS_*: Analysis Permissions
|
ANALYSIS_ANNOTATE, ANALYSIS_OWN_WARNINGS |
|
WPROCESSOR_*: Warning Processor Permissions
|
WPROCESSOR_EXECUTE |
For each launch daemon L, the associated Hub User (considered the
"owner" of L) is treated as if it has all LAUNCHD_* permissions for L, even if its
assigned roles would not otherwise confer those permissions.
In particular, if a launch daemon's associated Hub User is
special user Anonymous, users in
anonymous
sessions will have all LAUNCHD_*
permissions for that launch daemon. For this reason, we do not
recommend authenticating and
authorizing launch daemons as Anonymous unless you have a high degree of trust
in every person with access to the hub. To ensure your launch daemons
do not run as Anonymous, always use
a non- Anonymous hub user to
authenticate commands that explicitly or implicitly start
a launch daemon:
Note that configuration tool users may need to use Anonymous to authenticate the launch daemons
started for "Install, connect
to existing hub" and "Install, create
hub" commands because Administrator may be unsuitable and individual
user accounts may not yet exist.
Role-permission assignments can be viewed and modified from the
CodeSonar GUI.
Direct role-permissions are directly represented in the
underlying, normalized forms of the appropriate role-permission
tables in the CodeSonar database. Indirect role-permissions are not
represented in the normalized tables. However, for performance
reasons, the role-permission tables in the hub database are also
stored in denormalized forms in which both explicit and implicit
role-permissions are made fully explicit.
Role-permission changes due to normal CodeSonar operations are
denormalized automatically without any need for user action, but if
you use an SQL query to manually change role-permission
assignments, make sure that you always:
- operate only on tables with names of the form <resourcelabel>RolePermission
(not <resourcelabel>RolePermissionFlat,
which will be rewritten next time a denormalization is
triggered), and
- immediately follow up by visiting the hub's update_denorm_tables URL to manually
trigger denormalization.
icon. These links are available in tables of resources, pages about
individual resources, and certain other locations,.