[linux_acl]

Description

• The Saltstack state acl.present fails in various conditions. Failing means that it behaves differently than the command setfacl when the same options / parameters are provided.
• The Saltstack module acl.modfacl has a different behavior than the Saltstack state acl.present.

This problems make the state acl.present unusable. Saltstack has no reliable solution for managing ACLs - a basic Linux function. Saltstack-users have to manage ACLs with own scripts instead. I assume other configuration management tools have no problems with such a basic function.

The Linux engineers at Zurich University of Applied Sciences kindly ask the Saltstack developers to fix this state. We may support the development of a refactored version by supporting the developer with testing. Contact

Setup
on-prem vm, salt-master 3004.1 (Ubuntu 18.04)
on-prem vm, salt-minion 3004 (Ubuntu 18.04)

Details

• A folder structure is given, containing more files and folders.
• No ACLs are set.
• Ownership and permissions are set as such:

drwxrws--- 4 www-data www-data 4096 Jun 23 15:55 /TEST/typo3
drwxrws--- 4 www-data www-data 4096 Aug 17  2021 /TEST/typo3/version7

TEST A: Clear all ACLs, then check

# CLEAR ACLs:
setfacl -R -b /TEST/typo3

# TEST ACLs with Linux command:
getfacl /TEST/typo3
# file: TEST/typo3
# owner: www-data
# group: www-data
# flags: -s-
user::rwx
group::rwx
other::---

# TEST ACLs with Saltstack module command:
salt-call acl.getfacl /TEST/typo3
user:
            |_
              ----------
              www-data:
                  ----------
                  octal:
                      7
                  permissions:
                      ----------
                      execute:
                          True
                      read:
                          True
                      write:
                          True

PROBLEM 1
The salt module acl.getfacl combines the linux permissions (rwx) with the ACLs and indicates that ACLs are set. This is a bug. The command getfacl shows correctly, that no ACLs for user www-data are set.

TEST B: Set ACLs for user www-data and check
State to apply:

{{ slspath }}> Set ACLs TEST A:
  acl.present:
    - name: /TEST/typo3
    - acl_type: user
    - acl_name: www-data
    - perms: rwx

PROBLEM 2: The state will not apply ACLs required to be set. This is probably because the salt module falsely reports that ACLs are set.

Testing ACLs returns this result:

getfacl /TEST/typo3

# file: TEST/typo3
# owner: www-data
# group: www-data
# flags: -s-
user::rwx
group::rwx
other::---

• NOTE 1: The command will correctly apply ACLs: setfacl -m u:www-data:rwx /TEST/typo3
• NOTE 2: Also the salt module will correctly set ACLs: acl.modfacl user www-data rwx /TEST/typo3

TEST C: Set ACLs for user www-data by UID and check
State to apply:

{{ slspath }}> Set ACLs TEST B:
  acl.present:
    - name: /TEST/typo3
    - acl_type: user
    - acl_name: 33
    - perms: rwx

PROBLEM 3: Applying the ACLs by UID will correctly set the ACLs. But the ACLs are set repeatedly each time when the state applied.

More Problems
The state acl.present has countless errors and needs bug-fixes / refactoring by a person that really understands Linux ACLs. Some examples:

• The behavior of acl.present is different if the user is not the owner.
• If ACLs are set recursively in the above example, ACLs are set by acl.present. But...
• ...if then ACLs are deleted manually (not modified), such as: setfacl -b /TEST/typo3/ and/or: setfacl -b /TEST/typo3/version7 re-applying the state will not set the ACLs.

Today we are using scripts to set ACLs running by cmd.run. This is far from ideal and we should be able to use saltack acl.present - but this state is very buggy.

And of course we'd like to have the possibility to make use of the special permission perms:rwX for folders recursively. The large X specifies to set the execute-ACL on folders but not change ACLs on files.

Start at the Salt entry points acl.present, acl.getfacl, and acl.modfacl, then reproduce the reported cases with getfacl and setfacl on the provided directory structure. Compare state behavior with the module and native commands, including named users, numeric UIDs, recursive application, and repeated runs. Done means acl.present applies the requested ACLs consistently and remains idempotent after ACLs are removed.