sefcontext: new directories do not obtain the selinux context set by sefcontext

[marcindulak]

Summary

The documentation https://docs.ansible.com/ansible/2.9/modules/sefcontext_module.html says

The module does not modify existing files to the new SELinux context(s), so it is advisable to
first create the SELinux file contexts before creating files, or run restorecon manually for the
existing files that require the new SELinux file contexts.

The part it is advisable to first create the SELinux file contexts before creating files suggests that new files/directories may be created using the context defined using sefcontext. Also an older comment ansible/issues/33577#issuecomment-403003170 suggests this, but it does always not seem to be the case, as discussed also in selinux-canonical-way-of-automatically-applying-a-context-on-file-creation.

Here is an example that illustrates the problem:

cat play.yaml
---
- hosts: localhost
  become: True
  tasks:
  - name: Allow apache to modify files in /srv/git_repos
    sefcontext:
      target: '/srv/git_repos(/.*)?'
      setype: httpd_sys_rw_content_t
      state: present
      reload: yes
  - name: Create a directory
    file:
      state: directory
      path: /srv/git_repos

rm -rf /src

ansible-playbook play.yaml

semanage fcontext -l -C | grep srv
/srv/git_repos(/.*)?             all files          system_u:object_r:httpd_sys_rw_content_t:s0

Actual result:

ls -aldZ /srv/git_repos
drwxr-xr-x. 2 root root unconfined_u:object_r:var_t:s0 6 Apr 23 16:04 /srv/git_repos

Expected result (requires restorecon)

restorecon -vR /srv/git_repos
Relabeled /srv/git_repos from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_rw_content_t:s0

ls -aldZ /srv/git_repos
drwxr-xr-x. 2 root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 6 Apr 23 16:04 /srv/git_repos

However, it the file task sets the parameter to setype: _default parameter, a freshly created /srv/git_repos directory receives the expected selinux context.

Issue Type

Documentation Report

Component Name

sefcontext

Ansible Version

$ ansible --version
ansible 2.9.27
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /bin/ansible
  python version = 3.6.8 (default, Nov 17 2021, 16:10:06) [GCC 8.5.0 20210514 (Red Hat 8.5.0-3)]

Community.general Version

As part of ansible 2.9, no separate community modules are used.

$ ansible-galaxy collection list community.general
usage: ansible-galaxy collection [-h] COLLECTION_ACTION ...
ansible-galaxy collection: error: argument COLLECTION_ACTION: invalid choice: 'list' (choose from 'init', 'build', 'publish', 'install')

Configuration

$ ansible-config dump --only-changed

OS / Environment

$ cat /etc/*release | grep PRETTY
PRETTY_NAME="AlmaLinux 8.5 (Arctic Sphynx)"

$ rpm -q libselinux
libselinux-2.9-5.el8.x86_64

Additional Information

The it is advisable to first create the SELinux file contexts before creating files part needs more clarification about the expected behavior. Currently a solution, recommended in docs, consists of running restorecon after sefcontext, however this is reported as a "changed", possibly non-idempotent step by ansible:

- name: Apply new SELinux file context to filesystem
  command: restorecon -irv /srv/git_repos

Alternatively, using the file module and setting the setype: _default parameter, could be used to force the selinux context on new files/directories as expected.

Code of Conduct

• [X] I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description:

• plugins/modules/system/sefcontext.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @dagwieers click here for bot help

[ansibullbot]

Files identified in the description:

• plugins/modules/sefcontext.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[savchuk1985]

Hello! I have a similar problem with this module.

I need to create a directory, but I need to avoid explicitly setting the SELinux label using the file builtin module, since the label may be changed later if the directory is to be used for automounting:

- name: SELinux context is set to allow read-write access to user directories
  community.general.sefcontext:
    target: "/var/ftp/users(/.*)?"
    ftype: a
    seuser: system_u
    setype: public_content_rw_t
    state: present
  become: yes

- name: Root directory for virtual host serving home directories is created
  ansible.builtin.file:
    path: /var/ftp/users
    state: directory
    owner: ftp
    group: ftp
    mode: "0750"
  become: yes

After completing the tasks, I see that the label has not changed:

# semanage fcontext -l | grep /var/ftp/users
/var/ftp/users(/.*)?                               all files          system_u:object_r:public_content_rw_t:s0

# ls -lZd /var/ftp/users/
drwxr-x---. 2 ftp ftp unconfined_u:object_r:public_content_t:s0 6 Sep 17 14:49 /var/ftp/users/

If I set setype: _default I get the following problem when the automount point is already set:

TASK [proftpd : Root directory for virtual host serving projects is created] *********************************************************************************
fatal: [ftpdev.bp.local]: FAILED! => {"changed": false, "cur_context": ["system_u", "object_r", "autofs_t", "s0"], "gid": 50, "group": "ftp", "input_was": ["system_u", null, "public_content_t", null], "mode": "0750", "msg": "invalid selinux context: [Errno 95] Operation not supported", "new_context": ["system_u", "object_r", "public_content_t", "s0"], "owner": "ftp", "path": "/var/ftp/projects", "secontext": "system_u:object_r:autofs_t:s0", "size": 0, "state": "directory", "uid": 14}

This is an example for a different directory with a different label, but the principle is the same.

Can this issue be given a higher priority?