Changes with Linux ACL between 2018.3.3 and 2018.3.4

[knine]

Description of Issue/Question

It appears the acl.present state has a bug between versions 2018.3.3 and 2018.3.4. The following output is showing up during a test run in 2018.3.4:

      ID: Starfleet FACL
Function: acl.present
    Name: /path/to/directory
  Result: None
 Comment: Updated permissions will be applied for starfleet: 5 -> rx
 Started: 09:11:27.079996
Duration: 24350.106 ms
 Changes:   
          ----------
          new:
              ----------
              acl_name:
                  starfleet
              acl_type:
                  group
              perms:
                  rx
          old:
              ----------
              acl_name:
                  starfleet
              acl_type:
                  group
              perms:
                  5

This does not show up if I roll back to 2018.3.3. My guess is under the hood it is not seeing that "rx" is the same as "5". I can apply the changes, and it does it, but then the message re-appears again during a test run. I looked at the docs for the state and "perms" uses rwx, not numeric.

Setup

'Starfleet FACL':
  acl.present:
    - name: /path/to/directory
    - acl_type: group
    - acl_name: starfleet
    - perms: rx
    - recurse: True
    - require:
      - pkg: 'Starfleet Packages'

Steps to Reproduce Issue

Update from 2018.3.3 to 2018.3.4

Versions Report

Has issue:

Salt Version:
           Salt: 2018.3.4
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 1.5
          docker-py: 1.10.6
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.31.0
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.5 (default, Sep 12 2018, 05:31:16)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.3.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.1.4
 
System Versions:
           dist: redhat 7.6 Maipo
         locale: UTF-8
        machine: x86_64
        release: 3.10.0-957.5.1.el7.x86_64
         system: Linux
        version: Red Hat Enterprise Linux Server 7.6 Maipo

Rollback to fix:

Salt Version:
           Salt: 2018.3.3
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 1.5
      docker-py: 1.10.6
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.28.2
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
     pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.5 (default, Sep 12 2018, 05:31:16)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.3.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.1.4
 
System Versions:
           dist: redhat 7.6 Maipo
         locale: UTF-8
       machine: x86_64
        release: 3.10.0-957.5.1.el7.x86_64
         system: Linux
        version: Red Hat Enterprise Linux Server 7.6 Maipo

[garethgreenaway]

@knine Thanks for the report. Unfortunately I haven't been able to reproduce the issue above, using this state:

'Starfleet FACL':
  acl.present:
    - name: /tmp/51959
    - acl_type: group
    - acl_name: users
    - perms: rx
    - recurse: True

The permissions are updated correctly using 2018.3.3 and then using 2018.3.4 the permissions remain unchanged.

[knine]

Interesting. I rolled one of my systems back up to 2018.3.4 again after everything checks out, and the same error returns.

The "perms" thing in the setting that is sticking out to me in the report, how it sees "5" instead of "rx" and so it wants to change it since the YAML says "rx" (I'm assuming). Somewhere these two are not equating.

[knine]

I've encountered a case for "4" not equating to "r" as well.

      ID: makeitso
Function: acl.present
    Name: /var/log/captain.log
  Result: None
 Comment: Updated permissions will be applied for picard: 4 -> r
 Started: 12:54:29.494106
Duration: 7.994 ms
 Changes: 
          ----------
          new:
              ----------
              acl_name:
                  picard
              acl_type:
                  default:user
              perms:
                  r
          old:
              ----------
              acl_name:
                  picard
              acl_type:
                  default:user
              perms:
                  4

[knine]

If this helps...

# file: directory
# owner: root
# group: root
user::rwx
group::--x
group:starfleet:r-x
mask::r-x
other::--x

[garethgreenaway]

@knine That helped a lot. I was able to duplicate the issue. Thanks!

[garethgreenaway]

Closing this out as the fix is in the 2018.3 and later branches, and will be available in the next minor releases. If the problem persists, let us know and we can reopen this issue.