{"id":15156611,"url":"https://github.com/puppetlabs/puppetlabs-acl","last_synced_at":"2025-10-23T16:34:20.773Z","repository":{"id":839329,"uuid":"15139557","full_name":"puppetlabs/puppetlabs-acl","owner":"puppetlabs","description":"ACL (Access Control List) module","archived":false,"fork":false,"pushed_at":"2025-02-04T02:10:24.000Z","size":1071,"stargazers_count":19,"open_issues_count":1,"forks_count":57,"subscribers_count":167,"default_branch":"main","last_synced_at":"2025-03-30T18:11:09.584Z","etag":null,"topics":["hacktoberfest","module","supported"],"latest_commit_sha":null,"homepage":"","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/puppetlabs.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2013-12-12T15:26:49.000Z","updated_at":"2025-01-28T05:40:06.000Z","dependencies_parsed_at":"2023-02-17T07:01:13.087Z","dependency_job_id":"fdbbe2f2-d90d-4ee5-a2a5-ee021d445241","html_url":"https://github.com/puppetlabs/puppetlabs-acl","commit_stats":{"total_commits":530,"total_committers":51,"mean_commits":"10.392156862745098","dds":0.6169811320754717,"last_synced_commit":"31394f373811abecb8ec9a8d673d2b27995aa4b7"},"previous_names":[],"tags_count":24,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/puppetlabs%2Fpuppetlabs-acl","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/puppetlabs%2Fpuppetlabs-acl/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/puppetlabs%2Fpuppetlabs-acl/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/puppetlabs%2Fpuppetlabs-acl/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/puppetlabs","download_url":"https://codeload.github.com/puppetlabs/puppetlabs-acl/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247543591,"owners_count":20955865,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["hacktoberfest","module","supported"],"created_at":"2024-09-26T19:23:59.385Z","updated_at":"2025-10-23T16:34:20.684Z","avatar_url":"https://github.com/puppetlabs.png","language":"Ruby","funding_links":[],"categories":[],"sub_categories":[],"readme":"# acl\n\n#### Table of Contents\n\n1. [Module Description - What does the module do?](#module-description)\n1. [Setup - The basics of getting started with acl](#setup)\n    * [Beginning with acl - Installation](#beginning-with-acl)\n1. [Usage - The custom type available for configuration](#usage)\n    * [Manage a basic ACL with all parameters expressed](#manage-a-basic-acl-with-all-parameters-expressed)\n    * [Manage multiple permissions at once](#manage-multiple-permissions-at-once)\n    * [Same target, multiple resources](#same-target-multiple-resources)\n    * [Identify users and groups with SID or FQDN](#identify-users-and-groups-with-sid-or-fqdn)\n    * [Use multiple resources to manage the same target](#use-multiple-resources-to-manage-the-same-target)\n    * [Protect a target from inherited permissions](#protect-a-target-from-inherited-permissions)\n    * [Purge unmanaged explicit permissions](#purge-unmanaged-explicit-permissions)\n    * [Protect a target and purge all unmanaged permissions](#protect-a-target-and-purge-all-unmanaged-permissions)\n    * [Set ACE mask_specific rights](#set-ace-mask_specific-rights)\n    * [Explicitly deny permissions](#explicitly-deny-permissions)\n    * [Set ACE inheritance](#set-ace-inheritance)\n    * [Set ACE propagation](#set-ace-propagation)\n    * [Remove ACE permissions](#remove-ace-permissions)\n    * [Use same identity, multiple ACEs](#use-same-identity-multiple-aces)\n1. [Reference - An under-the-hood peek at what the module is doing and how](#reference)\n1. [Limitations - Known issues in acl](#limitations)\n1. [License](#license)\n1. [Development - Guide for contributing to the module](#development)\n\n## Module Description\n\nThe acl module lets you use Puppet to manage Access Control Lists (ACLs) on Windows.\n\nWindows uses Access Control Lists (ACLs) to store permissions information. An ACL is typically made up of a series of Access Control Entries (ACEs), representing individual permissions. The acl module adds a type and provider to let you manage all that information through Puppet.\n\n## Setup\n\nInstall this module with the following command:\n\n~~~puppet\n$ puppet module install [--modulepath \u003cpath\u003e] puppetlabs/acl\n~~~\n\nThe above command also includes the optional argument to specify your Puppet server's `modulepath` as the location to install the module.\n\n### Beginning with acl\n\nFor a basic implementation of the acl module, provide a target ACL and at least one permission:\n\n\n~~~puppet\nacl { 'c:/tempperms':\n  permissions =\u003e [\n   { identity =\u003e 'Administrator', rights =\u003e ['full'] },\n   { identity =\u003e 'Users', rights =\u003e ['read','execute'] }\n ],\n}\n~~~\n\n## Usage\n\n\nA typical ACL is made up of access control entries (ACEs), which represent individual permissions. Each ACE comprises a defined trustee (an identity, representing a user, group, or system process), a set of rights, an inheritance and propagation strategy, and an allowed/denied status.\n\nWindows processes ACEs in order of appearance within the ACL. It expects them to be pre-sorted by allowed/denied status in the following order:\n 1. 'explicit deny'\n 2. 'explicit allow'\n 3. 'inherited deny'\n 4. 'inherited allow'\n\nThe `acl` type does not enforce the above order, and applies the ACEs based on order of appearance in your manifest. If that differs from the ordering above, node users who view or update the ACL through the Windows Security graphical interface receive a warning message: \"The permissions on [filename] are incorrectly ordered, which may cause some entries to be ineffective.\"\n\n**Note:** You cannot specify inherited ACEs in a manifest; you can only specify whether to allow upstream inheritance to flow into the managed ACL.\n\n### Manage a basic ACL with all parameters expressed\n\nThe fully expressed ACL in the sample below produces the same settings as the [minimal sample](beginning-with-acl) in the Setup section, without relying on defaults.\n\n~~~puppet\nacl { 'c:/tempperms':\n  target                     =\u003e 'c:/tempperms',\n  purge                      =\u003e false,\n  permissions                =\u003e [\n   { identity =\u003e 'Administrator', rights =\u003e ['full'], perm_type=\u003e 'allow', child_types =\u003e 'all', affects =\u003e 'all' },\n   { identity =\u003e 'Users', rights =\u003e ['read','execute'], perm_type=\u003e 'allow', child_types =\u003e 'all', affects =\u003e 'all' }\n  ],\n  owner                      =\u003e 'Administrators', #Creator_Owner specific, doesn't manage unless specified\n  group                      =\u003e 'Users', #Creator_Group specific, doesn't manage unless specified\n  inherit_parent_permissions =\u003e true,\n}\n~~~\n\n\n### Manage multiple permissions at once\n\nThe `permissions` parameter is passed as an array, allowing it to accept multiple ACEs in the form of hashes.\n\n~~~puppet\nacl { 'c:/tempperms':\n  permissions                =\u003e [\n   { identity =\u003e 'Administrators', rights =\u003e ['full'] },\n   { identity =\u003e 'Administrator', rights =\u003e ['modify'] },\n   { identity =\u003e 'Authenticated Users', rights =\u003e ['write','read','execute'] },\n   { identity =\u003e 'Users', rights =\u003e ['read','execute'] }\n   { identity =\u003e 'Everyone', rights =\u003e ['read'] }\n  ],\n  inherit_parent_permissions =\u003e false,\n}\n~~~\n\n * Each ACE should have a unique combination of `identity`, `perm_type`, `child_types`, and `affects` values. If you create multiple ACEs that differ only in `rights`, the module can't tell them apart and wrongly reports that the resource is out of sync.\n\n\n**Wrong:**\n\n~~~puppet\nacl { 'c:/tempperms':\n  permissions =\u003e [\n    { identity =\u003e 'SYSTEM', rights =\u003e ['read']},\n    { identity =\u003e 'SYSTEM', rights =\u003e ['write']}\n  ],\n}\n~~~\n\n**Right:**\n\n~~~puppet\nacl { 'c:/tempperms':\n  permissions =\u003e [\n    { identity =\u003e 'SYSTEM', rights =\u003e ['read','write']}\n  ],\n}\n~~~\n\n**Note:** When you run `puppet resource acl some_path`, Puppet might list some permissions with the read-only element `is_inherited =\u003e 'true'`. If you use the `resource` output in a manifest, Puppet ignores those permissions. To indicate they should be enforced on the target directly, remove the `is_inherited` property or set `is_inherited =\u003e false'`.\n\nFor more detail, see the Reference section on [`permissions`](#permissions).\n\n### Identify users and groups with SID or FQDN\n\nYou can identify a user or group using a [security identifier](http://support.microsoft.com/kb/243330) (SID) or a fully qualified domain name (FQDN).\n\n~~~puppet\nacl { 'c:/tempperms':\n  permissions =\u003e [\n   { identity =\u003e 'NT AUTHORITY\\SYSTEM', rights =\u003e ['modify'] },\n   { identity =\u003e 'BUILTIN\\Users', rights =\u003e ['read','execute'] },\n   { identity =\u003e 'S-1-5-32-544', rights =\u003e ['write','read','execute'] }\n  ],\n}\n~~~\n\n#### Use multiple resources to manage the same target\n\nYou can manage the same target across multiple ACL resources, as long as each resource has a unique title.\n\n**Warning:** Use this feature with care; it can get confusing quickly. Do not set `purge =\u003e 'true'` on any of the resources that apply to the same target. Doing so causes thrashing in reports, as the permissions are added and removed on every catalog application.\n\n~~~puppet\nacl { 'c:/tempperms':\n  permissions =\u003e [\n   { identity =\u003e 'Administrator', rights =\u003e ['full'] }\n ],\n}\n\nacl { 'tempperms_Users':\n  target      =\u003e 'c:/tempperms',\n  permissions =\u003e [\n   { identity =\u003e 'Users', rights =\u003e ['read','execute'] }\n ],\n}\n~~~\n\n#### Protect a target from inherited permissions\n\nRemoving upstream inheritance is known as \"protecting\" the target. When an item is protected without `purge =\u003e true`, the inherited ACEs are copied into the target as unmanaged ACEs.\n\n~~~puppet\nacl { 'c:/tempperms':\n  permissions                =\u003e [\n   { identity =\u003e 'Administrators', rights =\u003e ['full'] },\n   { identity =\u003e 'Users', rights =\u003e ['full'] }\n  ],\n  inherit_parent_permissions =\u003e false,\n}\n~~~\n\n#### Purge unmanaged explicit permissions\n\nYou cannot purge inherited permissions; you can only purge explicit permissions. To lock down a folder to managed explicit ACEs, set `purge =\u003e true`. This only removes other explicit ACEs from the folder that are unmanaged by this resource. All inherited ACEs remain (see next example).\n\n~~~puppet\nacl { 'c:/tempperms':\n  purge       =\u003e true,\n  permissions =\u003e [\n   { identity =\u003e 'Administrators', rights =\u003e ['full'] },\n   { identity =\u003e 'Users', rights =\u003e ['full'] }\n  ],\n}\n~~~\n\n#### Protect a target and purge all unmanaged permissions\n\nTo fully restrict a target's permissions to the ones specified in your manifest, protect it as above and set `purge =\u003e 'true'`.\n\n**Warning**: When removing permissions, make sure the user running Puppet always has FULL rights on the target. If Puppet loses its permission to manage a resource, you'll need to restore it manually at the node level.\n\n~~~puppet\nacl { 'c:/tempperms':\n  purge                           =\u003e true,\n  permissions                     =\u003e [\n   { identity =\u003e 'Administrators', rights =\u003e ['full'] },\n   { identity =\u003e 'Users', rights =\u003e ['full'] }\n  ],\n  inherit_parent_permissions =\u003e false,\n}\n~~~\n\n#### Set ACE mask_specific rights\n\nIf none of the standard `rights` values meets your specific needs, you can specify more granular rights by setting `rights =\u003e ['mask_specific']` and supplying a 'mask' element with an integer representing a [permissions mask](http://msdn.microsoft.com/en-us/library/aa394063(v=vs.85).aspx). You can't combine the mask with other values, such as read permissions.\n\n**NOTE:** 'mask_specific' should ONLY be used when other rights are not specific enough. If you specify 'mask_specific' with the equivalent of 'full' rights (2032127), and Puppet finds the property to be 'full', it reports making changes to the resource even though nothing is different.\n\n~~~puppet\nacl { 'c:/tempperms':\n  purge                      =\u003e true,\n  permissions                =\u003e [\n   { identity =\u003e 'Administrators', rights =\u003e ['full'] }, #full is same as - 2032127 aka 0x1f01ff but you should use 'full'\n   { identity =\u003e 'SYSTEM', rights =\u003e ['modify'] }, #modify is same as 1245631 aka 0x1301bf but you should use 'modify'\n   { identity =\u003e 'Users', rights =\u003e ['mask_specific'], mask =\u003e '1180073' }, #RX WA #0x1201a9\n   { identity =\u003e 'Administrator', rights =\u003e ['mask_specific'], mask =\u003e '1180032' }  #RA,S,WA,Rc #1180032  #0x120180\n  ],\n  inherit_parent_permissions =\u003e false,\n}\n~~~\n\n**More about ACE masks:**\n\n * File/Directory Access Mask Constants: http://msdn.microsoft.com/en-us/library/aa394063(v=vs.85).aspx\n * Generic File Access Rights: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364399(v=vs.85).aspx\n * Access Mask Format: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374896(v=vs.85).aspx\n\n\n#### Explicitly deny permissions\n\nBy default, each ACE grants the described permissions to the target. However, you can reverse that by setting `perm_type =\u003e 'deny'`, which explicitly removes the described permissions. List your 'deny' ACEs first, before your 'allow' ACEs.\n\n~~~puppet\nacl { 'c:/tempperms':\n  permissions =\u003e [\n   { identity =\u003e 'SYSTEM', rights =\u003e ['full'], perm_type=\u003e 'deny', affects =\u003e 'self_only' },\n   { identity =\u003e 'Administrators', rights =\u003e ['full'] }\n  ],\n}\n~~~\n\n#### Set ACE inheritance\n\nThe inheritance structure of ACEs is controlled by [`child_types`](#permissions), which determine how files and sub-folders inherit each ACE.\n\n~~~puppet\nacl { 'c:/tempperms':\n  purge                      =\u003e true,\n  permissions                =\u003e [\n   { identity =\u003e 'SYSTEM', rights =\u003e ['full'], child_types =\u003e 'all' },\n   { identity =\u003e 'Administrators', rights =\u003e ['full'], child_types =\u003e 'containers' },\n   { identity =\u003e 'Administrator', rights =\u003e ['full'], child_types =\u003e 'objects' },\n   { identity =\u003e 'Users', rights =\u003e ['full'], child_types =\u003e 'none' }\n  ],\n  inherit_parent_permissions =\u003e false,\n}\n~~~\n\n#### Set ACE propagation\n\nACEs have propagation rules which guide how they apply permissions to containers, objects, children, and grandchildren. Propagation is determined by [`affects`](#permissions), which can take the value of: 'all', 'self_only', 'children_only', 'direct_children_only', and 'self_and_direct_children_only'. Microsoft has a [good matrix](http://msdn.microsoft.com/en-us/library/ms229747.aspx) that outlines when and why you might use each of these values.\n\n~~~puppet\nacl { 'c:/tempperms':\n  purge                      =\u003e true,\n  permissions                =\u003e [\n   { identity =\u003e 'Administrators', rights =\u003e ['modify'], affects =\u003e 'all' },\n   { identity =\u003e 'Administrators', rights =\u003e ['full'], affects =\u003e 'self_only' },\n   { identity =\u003e 'Administrator', rights =\u003e ['full'], affects =\u003e 'direct_children_only' },\n   { identity =\u003e 'Users', rights =\u003e ['full'], affects =\u003e 'children_only' },\n   { identity =\u003e 'Authenticated Users', rights =\u003e ['read'], affects =\u003e 'self_and_direct_children_only' }\n  ],\n  inherit_parent_permissions =\u003e false,\n}\n~~~\n\n#### Remove ACE permissions\n\nTo remove permissions, set `purge =\u003e listed_permissions`. This removes explicit permissions from the ACL based on their `identity`, `perm_type`, `child_types` and `affects` attributes. The example below ensures that 'Administrator' and 'Authenticated Users' are not on the ACL.\n\n~~~puppet\n# set permissions\nacl { 'c:/tempperms/remove':\n  purge                      =\u003e true,\n  permissions                =\u003e [\n   { identity =\u003e 'Administrators', rights =\u003e ['full'] },\n   { identity =\u003e 'Administrator', rights =\u003e ['write'] },\n   { identity =\u003e 'Users', rights =\u003e ['write','execute'] },\n   { identity =\u003e 'Everyone', rights =\u003e ['execute'] },\n   { identity =\u003e 'Authenticated Users', rights =\u003e ['full'] }\n  ],\n  inherit_parent_permissions =\u003e false,\n}\n\n# now remove some permissions\nacl { 'remove_tempperms/remove':\n  target                     =\u003e 'c:/tempperms/remove',\n  purge                      =\u003e 'listed_permissions',\n  permissions                =\u003e [\n   { identity =\u003e 'Administrator', rights =\u003e ['write'] },\n   { identity =\u003e 'Authenticated Users', rights =\u003e ['full'] }\n  ],\n  inherit_parent_permissions =\u003e false,\n  require                    =\u003e Acl['c:/tempperms/remove'],\n}\n~~~\n\n#### Same identity, multiple ACEs\n\nWith Windows, you can specify the same `identity` with different inheritance and propagation. Each of the resulting items is managed as a separate ACE.\n\n~~~puppet\nacl { 'c:/tempperms':\n  purge                      =\u003e true,\n  permissions                =\u003e [\n   { identity =\u003e 'SYSTEM', rights =\u003e ['modify'], child_types =\u003e 'none' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['modify'], child_types =\u003e 'containers' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['modify'], child_types =\u003e 'objects' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['full'], affects =\u003e 'self_only' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['read','execute'], affects =\u003e 'direct_children_only' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['read','execute'], child_types=\u003e'containers', affects =\u003e 'direct_children_only' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['read','execute'], child_types=\u003e'objects', affects =\u003e 'direct_children_only' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['full'], affects =\u003e 'children_only' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['full'], child_types=\u003e'containers', affects =\u003e 'children_only' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['full'], child_types=\u003e'objects', affects =\u003e 'children_only' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['read'], affects =\u003e 'self_and_direct_children_only' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['read'], child_types=\u003e'containers', affects =\u003e 'self_and_direct_children_only' },\n   { identity =\u003e 'SYSTEM', rights =\u003e ['read'], child_types=\u003e'objects', affects =\u003e 'self_and_direct_children_only' }\n  ],\n  inherit_parent_permissions =\u003e false,\n}\n~~~\n\n\n## Reference\n\n### Defined type: acl\n\nThe main type of the module, responsible for all its functionality.\n\n#### Parameters\n\nAll of the below parameters are optional, unless otherwise noted.\n\n##### `group`\n\nSpecifies whose permissions to manage. This identity is also known as a trustee or principal. If the identity doesn't exist on a node, Puppet creates it. Valid options: a string containing a valid identity (see below). Default: if left undefined, Puppet leaves the group as currently configured.\n\nValid identity formats:\n\n * User: e.g., 'Bob' or 'TheNet\\Bob'\n * Group: e.g., 'Administrators' or 'BUILTIN\\Administrators'\n * SID (Security ID): e.g., 'S-1-5-18'\n\n**NOTE**: On Windows the CREATOR GROUP inherited ACE must be set for the creator's primary group for it to be set as an ACE automatically. Group is not always widely used. By default, the group also needs to be specifically set as an explicitly managed ACE. See [Microsoft's page](http://support.microsoft.com/kb/126629) for instructions on enabling CREATOR GROUP.\n\n##### `inherit_parent_permissions`\n\nSpecifies whether to inherit permissions from parent ACLs. Valid options: 'true' and 'false'. Default: 'true'.\n\n##### `name`\n\nProvides a name for the ACL resource; also becomes the target, if `target` is not set. Valid options: a string. Default: the title of your declared resource.\n\n##### `owner`\n\nThe identity that owns the ACL. If the identity doesn't exist on a node, Puppet creates it. This identity is also known as a trustee or principal. Valid options: a string containing a valid identity (see below). Default: if left undefined, Puppet leaves the owner as currently configured.\n\nValid identity formats:\n\n * User: for example, 'Bob' or 'TheNet\\Bob'\n * Group: for example, 'Administrators' or 'BUILTIN\\Administrators'\n * SID (Security ID): for example, 'S-1-5-18'\n\n##### `permissions`\n\n*Required.* Specifies one or more Access Control Entries (ACEs). Valid options: an ordered array of hashes, each containing at least the `identity` and `rights` elements, and any number of additional elements from the list below.\n\n**Elements in `permissions`**\n\n * `affects`: *Optional.* Determines how the downstream inheritance is propagated. Valid options: 'all', 'self_only', 'children_only', 'self_and_direct_children_only', and 'direct_children_only'. Default: 'all'.\n\n * `child_types`: *Optional.* Determines how an ACE is inherited downstream from the target. Valid options: 'all', 'objects', 'containers' and 'none'. Default: 'all'.\n\n * `identity`: *Required.* Determines whose permissions to manage. If the specified identity doesn't exist on a node, Puppet creates it. Valid options: a user (e.g., 'Bob' or 'TheNet\\Bob'), group (e.g., 'Administrators' or 'BUILTIN\\Administrators'), or security ID (for example, 'S-1-5-18').\n\n\n * `mask`: *Required if `rights =\u003e 'mask_specific'` is set.* Indicates rights granted or denied to the trustee. If the `rights` element isn't set to 'mask_specific', the `mask` element has no effect. Valid options: an integer (set as a string, for example '511'), representing a [permissions mask](http://msdn.microsoft.com/en-us/library/aa394063(v=vs.85).aspx).\n\n  If you want more granular detail about `mask` values, we've provided an [ACL Mask Rights Addition spreadsheet](https://github.com/puppetlabs/puppetlabs-acl/blob/main/tools/ACL_Access_Rights_Mask_Addition.xlsx) in the acl module's `tools` directory.\n\n * `perm_type`: *Optional.* Specifies whether the target should or should *not* have the described permissions. Valid options: 'allow' and 'deny'. Default: 'allow'.\n\n\n * `rights`: *Required.*: Valid options: an array containing one or more of the following values: 'full', 'modify', 'mask_specific', 'write', 'read', and 'execute'.\n\n**NOTE:** The `type` element is deprecated and has been replaced with `perm_type`, because the word `type` will be a reserved keyword in Puppet 4.\n\n    * 'read', 'write', and 'execute' can be used together in any combination.\n    * 'modify' includes READ, WRITE, EXECUTE, and DELETE all in one.\n    * 'full' indicates all rights.\n    * 'full', 'modify', and 'mask_specific' values are mutually exclusive. If you use any of them, it must be the *only* `rights` value in the hash.\n    * If you specify 'full' or 'modify' along with other rights, e.g., `rights =\u003e ['full','read']`, the `acl` type issues a warning and removes the other items.\n    * If you specify 'mask_specific', you must also specify the `mask` element in the `permissions` hash with an integer representing a [permissions mask](http://msdn.microsoft.com/en-us/library/aa394063(v=vs.85).aspx).\n\n##### `purge`\n\nSpecifies whether to remove any explicit permissions not specified in the `permissions` property. Valid options: 'true', 'false', and 'listed_permissions'. Default: 'false'.\n\nTo ensure that a specific set of permissions are absent from the ACL, set `purge =\u003e 'listed_permissions'`.\n\n**Note:** This parameter only affects explicit permissions. To remove inherited permissions, use `inherit_parent_permissions =\u003e 'false'`.\n\n**Warning:** When removing permissions, make sure the user running Puppet always has FULL rights on the target. If Puppet loses its permission to manage a resource, you'll need to restore it manually at the node level.\n\n##### `target`\n\n*Optional.* The location of the ACL resource. Defaults to `name` value. Valid options: a string containing an absolute path. Default: title of your declared resource.\n\n## Limitations\n\n * The Windows Provider does not follow Symlinks. Please explicitly manage the permissions of the target.\n\n * The 8.3 short filename format used in some versions of Windows is not supported.\n\n * We don't recommend using the acl module with Cygwin, because it can yield inconsistent results --- especially when using Cygwin SSHD with public key authentication. For example, the 'Administrator' identity might work normally on Windows 2012, but on Windows 2008 it might be translated to 'cyg_server' (or vice-versa).\n\n * Unicode encoding isn't supported in the `identity`, `group`, or `owner` parameters.\n\n * When using SIDs for identities, autorequire tries to match to users with fully qualified names (e.g., User[BUILTIN\\Administrators]) in addition to SIDs (User[S-1-5-32-544]). However, it can't match against 'User[Administrators]', because that could cause issues if domain accounts and local accounts share the same name e.g., 'Domain\\Bob' and 'LOCAL\\Bob'.\n\n * When referring to accounts in the `APPLICATION PACKAGE AUTHORITY`, with Puppet versions older than **6.22.0** or **7.5.0**, use either their SID values or their unqualified names. The Windows API has well documented bugs preventing the fully qualifed account names from being used.\n\n    * `S-1-15-2-1` or `ALL APPLICATION PACKAGES`, but *not* `APPLICATION PACKAGE AUTHORITY\\ALL APPLICATION PACKAGES`. This account may only be referenced on Windows 2012R2 (kernel 6.3) or newer.\n    * `S-1-15-2-2` or `ALL RESTRICTED APPLICATION PACKAGES`, but *not* `APPLICATION PACKAGE AUTHORITY\\ALL RESTRICTED APPLICATION PACKAGES`. This account may only be referenced on Windows 2016 (kernel 10.0) or newer.\n\nPlease log tickets and issues at our [Module Issue Tracker](https://tickets.puppet.com/browse/MODULES).\n\n## License\n\nThis codebase is licensed under the Apache2.0 licensing, however due to the nature of the codebase the open source dependencies may also use a combination of [AGPL](https://www.gnu.org/licenses/agpl-3.0.en.html), [BSD-2](https://opensource.org/license/bsd-2-claus), [BSD-3](https://opensource.org/license/bsd-3-claus), [GPL2.0](https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html), [LGPL](https://opensource.org/license/lgpl-3-0/), [MIT](https://opensource.org/license/mit/) and [MPL](https://opensource.org/license/mpl-2-0/) Licensing.\n\n## Development\n\nWe are experimenting with a new tool for running acceptance tests. It's name is [puppet_litmus](https://github.com/puppetlabs/puppet_litmus) this replaces beaker as the test runner. To run the acceptance tests follow the instructions [here](https://github.com/puppetlabs/puppet_litmus/wiki/Tutorial:-use-Litmus-to-execute-acceptance-tests-with-a-sample-module-(MoTD)#install-the-necessary-gems-for-the-module).\n\nPuppet modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. We can’t access the huge number of platforms and myriad of hardware, software, and deployment configurations that Puppet is intended to serve.\n\nWe want to keep it as easy as possible to contribute changes so that our modules work in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.\n\nFor more information, see our [module contribution guide.](https://puppet.com/docs/puppet/latest/contributing.html)\n\n### Contributors\n\nTo see who's already involved, see the [list of contributors.](https://github.com/puppetlabs/puppetlabs-acl/graphs/contributors)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpuppetlabs%2Fpuppetlabs-acl","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpuppetlabs%2Fpuppetlabs-acl","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpuppetlabs%2Fpuppetlabs-acl/lists"}