You can implement and define security for objects.
A Rational Synergy database can contain many different collections
of objects. Group security restricts check out and modifies permissions
to a specified group of users for certain objects. In addition, you
can specify read security, which limits visibility of the source contents
of objects to designated groups.
If you work as the
group manager, use group security for the following reasons.
- Define a named group of users.
- Define and modify the users that are members of that named group.
- Restrict check out, read, and modify access of an object to specified
named groups by assigning one or more groups to it.
- restrict visibility of the source contents of a file to specified
named groups by assigning one or more groups with read source controls
to it.
A user working in a role that can create objects can restrict
access of an object to specified groups if that object is the only
version and the user can modify that object.
Read security is
implemented by providing access control to the source attribute of
an object. Users can query for objects and see other attributes regardless
of any read restrictions. Read security applies to source objects
that can be versioned, and does not apply to directories and projects.
However, if you apply read security to an object that is currently
in user work areas, those files are still readable by the users.
You
can define the following different levels of read access security:
- An object that has no read access restrictions to
its source can be accessed by any user.
- An object that has one or more groups defined for
read access allows access to the source if the user is a member of
at least one of those groups. All other users are denied access to
the source contents of that object.
- An object with the highest level of security (no
access to the source) cannot' be viewed, checked out, or modified,
but other attributes can be viewed. However, users working in the ccm_admin role
can always view the source contents of files.
Any object that is checked out inherits the same group security
restrictions as its predecessor, including read security restrictions.
Read security can only be used with copy-based work areas.
- When no groups exist, or no groups are assigned to an object,
there are no restrictions. Everyone can view, check out, and modify
source files.
- When one or more groups are created, and one group is assigned
to that object, only users in the specified group can view, check
out, and modify files. Users not in the specified group can only view
the source objects. In other words, check out and modify security
is implemented, but read security does not yet exist.
- When one or more groups are created, and one group is given read
security access (the ability to view source files), then all other
groups do not have read access to the files. After you start using
the read security option, access to source contents is denied by default.
If you have a directory in the public state
that uses group security and the user is not a member of any of the directory's
groups, the user can still create new objects, add them to, or remove
them from the directory. Users can easily overwrite each others' changes
if you use public directories; exercise caution when using public directories.
For
additional information about setting up databases for read security,
see Database read security. If you have a directory in the public state
that uses group security and the user is not a member of any of the groups
for the directory, the user can create objects, add them to, or remove
them from the directory. Users can easily overwrite each others' changes
if they use public directories; exercise caution
when using public directories.
The groups command supports
these subcommands: