aa addaclentry
creates ACL entries on the PTC RV&S Server
Synopsis
aa addaclentry [--acl=name] [--[no|confirm]allowNonexistentPrincipal] [--[no|confirm]createAcl] [--[no]inheritParentPermission] [--hostname=server] [--port=number] [ --password=password] [--user=name] [(-?|--usage)] [(-F file|--selectionFile=file)] [(-N|--no)] [(-Y|--yes)] [--[no]batch] [--cwd=directory] [--forceConfirm=[yes|no]] [(-g|--gui)] [--quiet] [--settingsUI=[gui|default]] [--status=[none|gui|default]] ACL entry...
Description
aa addaclentry creates new ACL entries on a specified PTC RV&S Server. Optionally, this allows creation of new ACLs. For example,
aa addaclentry --acl=mks:si:project:id:MKSProjects
g=developers:AddMember,!BreakLock,CheckIn,
CreateProject,CreateSubproject,!DropMember,
FetchRevision,Lock,ModifyMemberRev
creates ACL entries for the ACL named mks:si:project:id:MKSProjects, specifically assigning permissions to a principal group named developers, and results in:
Processing ACL entry...
developers: AddMember allowed
developers: BreakLock denied
developers: CheckIn allowed
developers: CreateProject allowed
developers: CreateSubproject allowed
developers: DropMember denied
developers: FetchRevision allowed
developers: Lock allowed
developers: ModifyMemberRev allowed
Options
This command takes the universal options available to all
aa commands, as well as some general options. See the
options reference page for descriptions.
• --acl=name
describes the ACL name.
The following server-level ACLs are shipped by default: mks default server level ACL providing root level administrative control over the PTC RV&S Server; mks:aa controlling login access to the ACLs; mks:aa:mks allowing read and update access for managing the ACLs; mks:patch controlling access to the administration of service packs; mks:im controlling access to managing workflows and documents; and mks:si controlling access to configuration management. For configuration management, you work with project ACLs that control the permissions for a particular directory. Working with member ACLs is also possible, which control permissions for specific files -- this would be for those rare circumstances where security on specific, individual files must be heavily controlled and where the administrative costs are known and accepted.
The ACL name itself follows a specific hierarchical format:
◦ The default server-level ACL is named mks:si. All project and member ACLs will inherit permissions from this one.
◦ Project-level ACL names include a specific prefix, taking the format mks:si:project:id:<project directory>. The project directory is relative to the root of the PTC RV&S Server.
◦ Subproject ACLs have the same format as projects, simply appending the subdirectories using colons (:) instead of slashes.
◦ Variant project ACLs take the format mks:si:project:devpath:<devpathname>:id:<project directory>. The variant project directory is specified including colons.
◦ Member ACLs simply specify the file name in the ACL name, such as mks:si:project:id:<project directory>:<member file name>.
◦ Archive ACLs specify the archive name in the ACL name, such as mks:si:archive:<archive path>.
• --[no|confirm]allowNonexistentPrincipal
controls whether to allow creation of an ACL entry for a nonexistent principal. When creating ACL entries, the PTC RV&S Server will look at your network authentication system and determine whether the principal is valid. If you specify --allowNonexistentPrincipal, any principal will be allowed.
• --[no|confirm]createAcl
controls whether to create a new ACL if it does not already exist.
• --[no]inheritParentPermission
specifies if to inherit permission of the parent configuration management project. This option to inherit parent permissions is only applicable to ACLs for configuration management (source) projects and development paths. For more information on permission inheritance, see the PTC RV&S Help Center.
• ACL entry...
identifies one or more ACL entries you want to add. Separate multiple entries with a space.
The entry consists of two main elements: u= or g= for identifying the principal (user or group), then a colon (:) followed by the comma-separated list of permissions you want to allow or deny. Denied permissions are preceded by an exclamation (!) mark.
◦ The principal is listed as u= or g=, representing user or group. For example, u=mkern or g=developers.
◦ The comma-separated list of permissions are taken from those listed on the
ACL reference page. Denied permissions are preceded by an exclamation (!) mark. Remember to precede the list of permissions with a colon (:) to identify it with the principal. For example,
g=developers:AddLabel,!BreakLock.
Diagnostics
See the
diagnostics reference page for possible exit status values.
See Also