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:
```yaml
{{ 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.

saltstack / salt

[linux_acl] #62210