voxpupuli/puppet-posix_acl

A puppet module for POSIX ACLs

puppet-posix_acl's Issues

Race condition with non existing file and recursemode => deep

test.pp:

  '/etc/test/foo.pp':
    ensure => present,
}
file{
  '/etc/test':
    ensure => directory,
}
acl {
  '/etc/test':
    action      => set,
    permission  => ["group:root:r-x"],
    recursive   => true,
    recursemode => deep,
}

Result:

# /opt/puppetlabs/bin/puppet apply foo.pp
Notice: Compiled catalog for example.com in environment production in 0.14 seconds
Error: Failed to apply catalog: Execution of '/usr/bin/getfacl --absolute-names --no-effective /etc/test/foo.pp' returned 1: getfacl: /etc/test/foo.pp: No such file or directory

Unexpected Corrective Changes

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.4.4
• Ruby: 2.5.3
• Distribution: RHEL 7
• Module version: 1.0.0

How to reproduce (e.g Puppet code you use)

I'm trying to ensure a subset of ACLs on a file using the set command. Here's an example of what I'm doing.

file { "/some/example_dir":
   ensure => directory,
   group  => $owning_group,
   mode   => '0770',
} ->
posix_acl { "/some/example_dir":
   action     => set,
   provider   => posixacl,
   permission => ["group:${co_owning_group}:r-x",'user:${special_user}:r-x'],
   recursive  => false,
}

What are you seeing

I get a continuous corrective change that says the permissions will be changed from:
"group::rwx", "group:co_owning_group:r-x", "mask::rwx", "other::---", "user::rwx", "user:special_user:r-x"
to
"group:co_owning_group:r-x", "user:special_user:r-x"

What behavior did you expect instead

I would expect that the ACLs would be overlayed, and further runs would not produce a need for puppet to do a corrective change.

This is the way the module functioned under release 0.1.1. It would simply overlay the permissions and any existing permissions would not be taken into consideration. This seems to be inline with the description of how the set function is supposed to work (as opposed to the exact function.)

Any additional information you'd like to impart

This issue seems to be slightly different from the one opened by @Bouke

I'm perfectly fine with the way the permissions are getting set. It just seems to be a slight issue with the Puppet logic that evaluates whether or not a corrective changes is needed.

Solaris support

Hello!

I think it would be easy to add Solais OS support just by taking car of some issues related with getfacl and setfacl specific commands in that OS.

For example, getfacl command under Solaris does not support --absolute-names neither --no-efective arguments.

Is there any chance that you fix this problem. Could I collaborate somehow?

Kind Regards,

Raúl

Version release

Do you think a version release would be possible soon?
The latest version 0.1.1 dates back to Oct 14, 2018.
We are interested particularly in #66 as well as #65.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.10.12
• Ruby: -
• Distribution: CentOS 7
• Module version: 0.1.1

How to reproduce (e.g Puppet code you use)

What are you seeing

What behaviour did you expect instead

Output log

Any additional information you'd like to impart

posix_acl does not work with wildcards

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet:
• Ruby:
• Distribution:
• Module version:

How to reproduce (e.g Puppet code you use)

What are you seeing

What behaviour did you expect instead

Output log

Any additional information you'd like to impart

wildcard on directory path not being supported

When given getfacl /home/ss/ff/app/EXTRACT_* this works when run on the linux server . But the module is not able to support this , it gives path cannot be found

File is executable when X option is set on directory

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.7.2
• Ruby:
• Distribution: CentOS 7
• Module version: Last commit, after fe6c5ca

Scenario

Hi
I have this directory with the following permissions:

ls -l /backup2
total 0
-rw-r--r--. 1 root     root      0 ago  2 15:40 file0
drwx------. 2 postgres postgres 19 ago  2 15:40 test1
drwx------. 2 root     root      6 ago  2 15:39 test2

How to reproduce (e.g Puppet code you use)

posix_acl { "/backup2":
    action     => set,
    permission => [
      'user:syncuser:rwX',
      'mask::rwX',
    ],
    recursive  => true,
   }

What are you seeing

File /backup2/file0 is executable

getfacl file0
# file: file0
# owner: root
# group: root
user::rw-
user:syncuser:rwx
group::r--
mask::rwx
other::r--

What behaviour did you expect instead

File /backup2/file0 is not executable.
I would expect every file inside /backup2 to be not executable and every dir inside /backup executable.

getfacl file0
# file: file0
# owner: root
# group: root
user::rw-
user:syncuser:rw-
group::r--
mask::rw-
other::r--

Debug log

Executing: '/usr/bin/setfacl -R -n -m user:syncuser:rwx /backup2'
Executing: '/usr/bin/setfacl -R -n -m mask::rwx /backup2'

Any additional information you'd like to impart

If I run setfacl -n -R -m u:syncuser:rwX /backup2 and setfacl -n -R -m m::rwX /backup2 manually the result is the expected one with file0 being not executable

Oracle Linux: Warning about multiple default providers

We are using the posix_acl module on some Oracle Linux 7 Servers.
Oracle Linux is binary compatible to RedHat Enterprise Linux or CentOS.

When i start puppet, i get the following warning message from posix_acl module:
Info: Using configured environment 'XXXX' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Retrieving locales Info: Loading facts Warning: Found multiple default providers for posix_acl: genericacl, posixacl; using genericacl Info: Caching catalog for XXXX Info: Applying configuration version '1623935894' Notice: Applied catalog in 19.77 seconds

I also set the correct provider in the puppet code where i wanna use posix_acl:
posix_acl { 'XXX': provider => posixacl, action => set, permission => [ "XXX" ], require => [ User['XXX'], ], recursive => true, }

How can i resolve this warning about the multiple default providers and force the module to use posic_acl?

Or can this warning be ignored cause i set the correct provider within the puppet code?

Maybe also a bug with using posix_acl on a Oracle Linux Machine.

Thanks in advance!

setfacl recursive behavior extremely slow

Running Puppet over a list of permissions causes setfacl to run on a for loop through every permission in the list,
this is extremely inefficient, specially with very large sets of folders

Example code

 -> posix_acl { "${install_root}/accounts":
    action     => set,
    permission => [
      'group:engr:r-X',
      'group:cs:r-X',
      'default:group:engr:r-X',
      'default:group:cs:r-X'
    ],
    recursive  => true,
  }

This results in

/usr/bin/setfacl -R -n -m default:group:cs:r-X /data/accounts
/usr/bin/setfacl -R -n -m default:group:engr:r-X /data/accounts
/usr/bin/setfacl -R -n -m group:cs:r-X /data/accounts
/usr/bin/setfacl -R -n -m group:engr:r-X /data/accounts

Instead the proper and 4x faster run would be

/usr/bin/setfacl -R -n -m group:cs:r-X -m group:engr:r-X -m group:ops:r-X -m default:group:ops:r-X -m default:group:engr:r-X -m default:group:cs:r-X /data/accounts/

Is there any way to change this behavior? We have very large filesystem data sets and this method causes puppet timeout failures

module name conflict

FYI there was already a module that used acl as its folder name: puppetlabs/acl

That module is needed for managing perms on Windows so this is creating a conflict when both Linux and Windows nodes are managed by the same puppetmaster.

FrozenStringLiteral breaks puppet module

The introduction of FrozenStringLiteral made yesterday (2022-01-20) to comply with Rubocop defaults causes Puppet catalog compilation errors.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: Agent 6.26.0 / Puppetserver 6.18.0
• Ruby: Agent 2.5.9p229 / Puppetserver jruby 9.2.17.0 (2.5.8)
• Distribution: Agent RHEL 8.5 / Puppetserver RHEL 7.9
• Module version: latest/master

How to reproduce (e.g Puppet code you use)

class acl_testing_class {
  file { '/var/log/acl_test':
    ensure => directory,
  }

  posix_acl { '/var/log/acl_test':
    action     => set,
    permission => [
      'user::rwx',
      'group::rwx',
      'other::rwx',
      'default:user::rwx',
      'default:group::rw-',
      'default:other::rw-',
    ],
    provider   => posixacl,
    recursive  => false,
  }
}

What are you seeing

Errors during catalog compilation

What behaviour did you expect instead

Successfully compilation of catalog

Output log

Failed to apply catalog: Parameter permission failed on Posix_acl[/var/log/acl_test]: Munging failed for value "default:user::rwx" in class permission: can't modify frozen String (file: /etc/puppetlabs/code/environments/production/modules/service_module/manifests/init.pp, line: 56)

Any additional information you'd like to impart

When reverting back to commit af9fdf8 , the module works again

Does this support Ubuntu?

At a first glance, it should not be a problem to run this on Ubuntu 18.04 and above.

Is it just missing a metadata.json entry?

ACLs based on numerical UID result in repeated re-apply.

My example:

  posix_acl { "filename":
    action => set,
    permission => [
      'user:2001:r--',
      'user:2002:r--',
    ],
  }

Results in:

Notice: /Stage[main]/Stunnel/Posix_acl/permission: current_value ["group::r--", "other::---", "user::rw-","user:phil:r--", "user:bob:r--"], should be ["user:2001:r--", "user:2002:r--"]

phil is user 2001, bob is user 2002. Puppet wants to re-apply this every time the code is run. (I know, silly example, why would you do that? but I have a use case for which this would be useful.)

The check will always fail because the check is made against the resolved usernames not the userIDs (and as an aside the check seems to be made against the complete getfacl output not the specific lines, but that's the gist of the other Issue linked). The code should check if a line match is found based on /either/ numerical id /or/ username.

This is a side-issue from the add this is linked to, and seems to be a separate case worthy of separate consideration, IMO.

Originally posted by @matt-matt2 in #58 (comment)

posix_acl fails to purge ACLs

        include posix_acl::requirements
        user { 'blub':
          ensure => 'present',
        }
        file { '/opt/test':
          ensure => directory,
          owner  => root,
          group  => root,
          mode   => '2770',
        }
        -> posix_acl { '/opt/test':
          action     => exact,
          permission => [
            'user::rwx',
            'group::rwx',
            'mask::rwx',
            'other::---',
            'user:blub:r-x',
            'user:blub2:r-x',
          ],
          provider   => posixacl,
          recursive  => false,
          require => User['blub'],
        }

let's say we've a posix_acl that sets an ACL for blub. Maybe in the future you want to allow user blub2 but deny user blub:

        include posix_acl::requirements
        user { ['blub', 'blub2']:
          ensure => 'present',
        }
        file { '/opt/test':
          ensure => directory,
          owner  => root,
          group  => root,
          mode   => '2770',
        }
        -> posix_acl { '/opt/test':
          action     => exact,
          permission => [
            'user::rwx',
            'group::rwx',
            'mask::rwx',
            'other::---',
            'user:blub2:r-x',
          ],
          provider   => posixacl,
          recursive  => false,
          require => User['blub2'],
        }

Puppet will fail to remove the 'user:blub:r-x', ACL. #109 Has a test to reproduce this. #108 has a fix for this.

modules/posix_acl/lib/puppet/type/posix_acl.rb:82: unknown type of %string

942e335 causes an error occurring on the puppetserver-side for me. Probably a compatibility issue as I'm still stuck to Puppet5 (v5.3.11).

puppetserver    | 2020-01-22 15:08:23,502 ERROR [qtp661065012-23] [puppetserver] Puppet Evaluation Error: Error while evaluating a Virtual Query, Could not autoload puppet/type/posix_acl: /etc/puppetlabs/puppet/modules/posix_acl/lib/puppet/type/posix_acl.rb:82: unknown type of %string
puppetserver    |   %i[posix_acl file].each do |autorequire_type|
puppetserver    |     ^ (file: /data/puppet-modules/production/current/puppet-modules/local-modules/monitoring/manifests/init.pp, line: 56, column: 6) on node host.example.com

[RFE] Extend File type to eliminate need for redundant code

Currently, the Acl type only operates on files and directories that exist. This means that a matching File resource is needed to guarantee that the Acl resource requirements are met. This also means that the mode property for the File resource must match the three base entries in the Acl permission property. See: https://github.com/dobbymoodge/puppet-acl#conflicts-with-file-resource-type

I propose that the Acl type be modified to extend the File type, so that all the properties available in the File type are exposed or overridden by the Acl type. I think this should be straightforward, but some properties may conflict (i.e. the Acl {'permission'} and File {'mode'} properties). These need to be specifically addressed:

• The mode property will not be exposed, and the values for the base entries in the Acl {'permission'} property will be used internally to supply File {'mode'}
• The File {'recurselimit'} property will need a matching, overriding implementation in the Acl type.
• ???

README not displaying in forge

The README tab is not currently showing in puppet forge for this module. Would be handy for the README to display rather than the changelog.

Append-only mode?

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.10
• Ruby: ?
• Distribution: CentOS 7.4
• Module version: 0.1.1

How to reproduce (e.g Puppet code you use)

    posix_acl { '/var/opt/rh/rh-haproxy18/lib/haproxy/stats':
        action     => set,
        permission => [
            "user:zabbix:rw-",
        ],
        require    => [Package['rh-haproxy18']],
    }

What are you seeing

Notice: /Stage[main]/Profile::Monitoring::Load_balancer/Posix_acl[/var/opt/rh/rh-haproxy18/lib/haproxy/stats]/permission: permission changed '["group::---", "other::---", "user::rw-"]' to '["user:zabbix:rw-"]'

[root@lb03 ~]# getfacl /var/opt/rh/rh-haproxy18/lib/haproxy/stats
getfacl: Removing leading '/' from absolute path names
# file: var/opt/rh/rh-haproxy18/lib/haproxy/stats
# owner: haproxy
# group: haproxy
user::rw-
user:zabbix:rw-			#effective:---
group::---
mask::---
other::---

What behaviour did you expect instead

[root@lb03 ~]# setfacl -m u:zabbix:rw /var/opt/rh/rh-haproxy18/lib/haproxy/stats
[root@lb03 ~]# getfacl /var/opt/rh/rh-haproxy18/lib/haproxy/stats
getfacl: Removing leading '/' from absolute path names
# file: var/opt/rh/rh-haproxy18/lib/haproxy/stats
# owner: haproxy
# group: haproxy
user::rw-
user:zabbix:rw-
group::---
mask::rw-
other::---

Any additional information you'd like to impart

The documentation says that the "set" operation should leave existing permissions alone. However it still replaces the user/group/other permissions.

Is the module compatible with Puppet 7.x ?

Hello,

Module is noted as compatible with Puppet >= 5.5.8 < 7.0.0 in the metadata.json.

Does the code needs some kind of rework to be compatible with Puppet < 8.0.0?

Regards,

Missing documentation for recursemode option?

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.0.0
• Ruby: 2.5.5
• Distribution: Debian
• Module version: 1.1.0

How to reproduce (e.g Puppet code you use)

I cannot find references to recursemode (lazy, deep) option in README file, is it normal?
As far as I understand, setting it to "deep" is needed when top-level files/directories have correct rights, but other files have not.

What are you seeing

What behaviour did you expect instead

Output log

Any additional information you'd like to impart

Directory +x / Files not +x

Hi

It does not seem possible to do setfacl -R -m u:myuser:rwX myfolder

Any idea (except no-recurse/give all subfiles) ?

Best regards

Request: Publish v1.0.1 to Forge

Do you think the current Tag (from January) can be published to forge? Or is there a reason not to?
Currently v1.0.0 is the most up-to-date version and we'd love to pull it from forge (rather than from github).

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: -
• Ruby: -
• Distribution: -
• Module version: v1.0.1

How to reproduce (e.g Puppet code you use)

What are you seeing

What behaviour did you expect instead

v1.0.1 is available via https://forge.puppet.com/modules/puppet/posix_acl

Output log

Any additional information you'd like to impart

AD group causes corrective action every puppet run

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.3.5
• Ruby:
• Distribution: CentOS 7
• Module version: 1.0.0

How to reproduce (e.g Puppet code you use)

posix_acl { '/mnt/test':
        action     => exact,
        permission => [
            'default:user::rwx',
            'default:group::rwx',
            'default:mask::rwx',
            'default:other::---',
            'user::rwx',
            'group::rwx',
            'mask::rwx',
            'other::---',
            "user:${ad_domain_short_caps}\\tmashos:rwx",
        ],
        recursive  => true,
        require    => Package['acl'],
    }

What are you seeing

Puppet tries to correct the ACL every time

What behaviour did you expect instead

Puppet doesn't change the ACL when it's correct

Output log

Notice: /Stage[main]/Profile::Mssql::Linux_server/Posix_acl[/mnt/test]/permission: permission changed ["default:group::rwx", "default:mask::rwx", "default:other::---", "default:user::rwx", "group::rwx", "mask::rwx", "other::---", "user::rwx", "user:HOSTING-US\134tmashos:rwx"] to ["default:group::rwx", "default:mask::rwx", "default:other::---", "default:user::rwx", "group::rwx", "mask::rwx", "other::---", "user::rwx", "user:HOSTING-US\tmashos:rwx"]

Any additional information you'd like to impart

This is using a LDAP (Active Directory) user in an ACL called "HOSTING-US\tmashos". getfacl formats the \ as \134 so it doesn't match what is set it puppet when it's returned.

Publish to the forge

I would like to see 0.0.3 published to the forge, thanks :-)

Recursive doesn't appear to work

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.5.21
• Ruby: 2.5.5p157
• Distribution: RedHat
• Module version: 1.0.0

How to reproduce (e.g Puppet code you use)

posix_acl { '/var/log':
    action     => set,
    permission => [
      'user::rwx',
      'group::r-x',
      'other::---',
      'mask::r-x',
      'user:dd-agent:rx',
    ],
    provider   => posixacl,
    recursive  => true,
  }

What are you seeing

It only applies to /var/log and not any subfiles

What behaviour did you expect instead

To recursively set all files within with the same permissions

Output log

Notice: /Stage[main]/Profile::Logs/Posix_acl[/var/log]/permission: permission changed ["group::r-x", "mask::r-x", "other::r-x", "user::rwx", "user:dd-agent:r-x"] to ["group::r-x", "mask::r-x", "other::---", "user::rwx", "user:dd-agent:r-x"]
# ls -la /var/log
total 758120
drwxr-x---+ 15 root     root          4096 Aug  9 03:28 .
drwxr-xr-x. 19 root     root           267 Sep  4  2018 ..
drwxr-x---+  2 root     root           232 Sep  4  2018 anaconda
drwx------+  2 root     root            99 Aug  9 17:01 audit
-rw-------+  1 root     root             0 Nov 29  2019 boot.log
...

Not even boot.log was changed to new permissions

Any additional information you'd like to impart

Move to Vox Pupuli

What do you think about moving puppet-acl to Vox Pupuli to get more people working on it, and get higher visibility plus better standards?

Accept short acls.

They appear to work but I get a warning bellow unless all the acl's are in long form.

Notice: /Stage[main]/Srv/Acl[/srv/]/permission: permission changed 'default:group::r-x,default:other::--x,default:user::rwx,group::r-x,other::--x,user::rwx' to 'u::rwx,g::r-x,o::--x,d:u::rwx,d:g::r-x,d:o::--x'

It would be nice to be able to use d:u::rx for example, without generating this warning. This form is accepted by the setfacl command so it is standard.