User module creates home directory for existing user with incorrect SELinux types and permissions.

[chriskarel]

From @chriskarel on November 3, 2016 19:21

ISSUE TYPE

• Bug Report

COMPONENT NAME

User module

ANSIBLE VERSION

# ansible --version
ansible 2.3.0.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides
  python version = 2.7.13 (default, May 10 2017, 20:04:28) [GCC 6.3.1 20161221 (Red Hat 6.3.1-1)]

CONFIGURATION

Nothing unusual

OS / ENVIRONMENT

OEL/RHEL 7

SUMMARY

Using the user module on an existing user, but changing their home directory, results in the new home directory created with improper filesystem permissions and SELinux types.

STEPS TO REPRODUCE

Have an existing user, with an existing home directory setting. Then use the Ansible user module to change that home directory. The new directory will be created, but with the same permissions and SELinux values as the parent directory, rather than the usual home settings.

# cat bugtest.yaml 

---
- name: Showcase bug
  hosts: all
  tasks:
    - name: Create system accounts
      user:
        name={{item}}
        home=/home/{{item}}
        state=present
      with_items:
         - user_existing
         - user_not_existing


# useradd -d /home/userold user_existing
# ls -lZd /home/user*
drwx------. user_existing user_existing unconfined_u:object_r:user_home_dir_t:s0 /home/userold

<run the above playbook for this host>

# ls -lZd /home/user*
drwxr-xr-x. user_existing     user_existing     unconfined_u:object_r:home_root_t:s0 /home/user_existing
drwx------. user_not_existing user_not_existing unconfined_u:object_r:user_home_dir_t:s0 /home/user_not_existing
drwx------. user_existing     user_existing     unconfined_u:object_r:user_home_dir_t:s0 /home/userold

EXPECTED RESULTS

I would expect the new home directory that is created for an existing user would have similar permissions and SELinux values as a new home directory created for a brand new user. (eg: permissions of 0700, type of user_home_dir_t)
This also impacts the .ssh directory, if generate_ssh_key is true. I would expect the .ssh directory to have ssh_home_t type, but it does not.

ACTUAL RESULTS

The new home directory inherits the parent's permissions and SELinux context. In this case, that's mode 0755 and home_root_t, the same as /home/. /home/user_existing/ should look more like /home/userold/.

# ls -lZd /home/user*
drwxr-xr-x.   user_existing     user_existing     unconfined_u:object_r:home_root_t:s0 /home/user_existing
drwx------.   user_not_existing user_not_existing unconfined_u:object_r:user_home_dir_t:s0 /home/user_not_existing
drw-------.   user_existing     user_existing     unconfined_u:object_r:user_home_dir_t:s0 /home/userold

Copied from original issue: ansible/ansible-modules-core#5481

[chriskarel]

From @ansibot on November 3, 2016 19:59

@ansible ping, this issue is waiting for your response.
click here for bot help

[chriskarel]

From @ansibot on November 19, 2016 10:1

@ansible, ping. This issue is still waiting on your response.
click here for bot help

[chriskarel]

From @ansibot on December 7, 2016 19:58

This repository has been locked. All new issues and pull requests should be filed in https://github.com/ansible/ansible

Please read through the repomerge page in the dev guide. The guide contains links to tools which automatically move your issue or pull request to the ansible/ansible repo.

[chriskarel]

From @andrewrothstein on January 3, 2017 17:9

Bueller?

[chriskarel]

From @fzdarsky on February 7, 2017 10:12

Confirming issue exists also in Ansible 2.2.1.0 on Fedora 25.

[lifeofguenter]

under Debian + ansible 2.3.0 I am having the issue that system users are created with root:root homedir ?

Maybe related to: 507b96f#diff-8f60df5685f83b8659a1106d36591e93 ?

It seems to be a regression, as with earlier version I did not have issues.

[alikins]

ping @bcoca (merged #19464)
ping @rqelibari (author of #19464)

[kelu27]

Same issue with ansible 2.3.0.0 on macOS Sierra 10.12.4, when deploying to Ubuntu 16.04.2 LTS.
Users are created with root:root

[rqelibari]

@alikins Thank you for the notification!
The changes introduced by #19464 are macOS specific. The subclass those changes affect is not executed on other platforms but macOS.

About the problem:
The user module uses the usermod command, to do the required changes, if the user already exists. Else, that is if the user does not exist, it uses useradd instead.

Solutions:
I can fix this very easily, but - and this is important - only if it is not a useradd/usermod bug.

If the latter is not the case, I intend to extend the user module such that it fixes the permissions and SELinux types itself.
If it is a bug of one of those two, then I propose that someone of us reports it on the linux mailinglist, so that it can be fixed.

As I don't have access to an OEL/RHEL 7 nor to an Ubuntu system currently, I need your (@chriskarel and @lifeofguenter) help for checking that option. Please do the following on your systems and post the terminal log here afterwards:

• Create a new user with useradd -m -d /home/new_user new_user
• List the permissions of the home directory ls -lZd /home
• Change the users home directory with usermod -d /home/new_user_new_home new_user
• List the permissions of the new home directory ls -lZd /home

Quickfixes:
A quickfix for now is of course to use the file module and set things straight.

[alikins]

@rqelibari I'll see if I can get a RHEL7 test, but for references, the results on fedora 25:

[fedora-25:ansible (devel u=)]$ ls -lZd /home/
drwxr-xr-x. 4 root root system_u:object_r:home_root_t:s0 4096 May 22 15:53 /home/

[fedora-25:ansible (devel u=)]$ ls -lZd /home/*
drwx------. 22 adrian adrian unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 14:23 /home/adrian
drwx------.  2 root   root   system_u:object_r:lost_found_t:s0        16384 May  2 23:36 /home/lost+found

[fedora-25:ansible (devel u=)]$ sudo useradd -m -d /home/test_user test_user

[fedora-25:ansible (devel u=)]$ ls -lZd /home/
drwxr-xr-x. 5 root root system_u:object_r:home_root_t:s0 4096 May 22 15:54 /home/

[fedora-25:ansible (devel u=)]$ ls -lZd /home/*
drwx------. 22 adrian    adrian    unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 14:23 /home/adrian
drwx------.  2 root      root      system_u:object_r:lost_found_t:s0        16384 May  2 23:36 /home/lost+found
drwx------.  3 test_user test_user unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 15:54 /home/test_user

[fedora-25:ansible (devel u=)]$ sudo usermod -d /home/test_user_new_home test_user

[fedora-25:ansible (devel u=)]$ ls -lZd /home/
drwxr-xr-x. 5 root root system_u:object_r:home_root_t:s0 4096 May 22 15:54 /home/

[fedora-25:ansible (devel u=)]$ ls -lZd /home/*
drwx------. 22 adrian    adrian    unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 14:23 /home/adrian
drwx------.  2 root      root      system_u:object_r:lost_found_t:s0        16384 May  2 23:36 /home/lost+found
drwx------.  3 test_user test_user unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 15:54 /home/test_user

To get the usermod to create the new dir, had to add the -m to the second usermod invocation:

[fedora-25:ansible (devel u=)]$ sudo useradd -m -d /home/test_user2 test_user2

[fedora-25:ansible (devel u=)]$ ls -lZd /home/*
drwx------. 22 adrian     adrian     unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 14:23 /home/adrian
drwx------.  2 root       root       system_u:object_r:lost_found_t:s0        16384 May  2 23:36 /home/lost+found
drwx------.  3 test_user  test_user  unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 15:54 /home/test_user
drwx------.  3 test_user2 test_user2 unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 15:58 /home/test_user2

[fedora-25:ansible (devel u=)]$ sudo usermod -m -d /home/test_user2_new_home test_user2

[fedora-25:ansible (devel u=)]$ ls -lZd /home/*
drwx------. 22 adrian     adrian     unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 14:23 /home/adrian
drwx------.  2 root       root       system_u:object_r:lost_found_t:s0        16384 May  2 23:36 /home/lost+found
drwx------.  3 test_user  test_user  unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 15:54 /home/test_user
drwx------.  3 test_user2 test_user2 unconfined_u:object_r:user_home_dir_t:s0  4096 May 22 15:58 /home/test_user2_new_home

[chriskarel]

@rqelibari
I have access to RHEL boxes for testing. But usermod doesn't look to solve any problems when an existing user didn't have a home directory created. Usermod can change the value of a users' home directory, and move it if the location doesn't exist. But it won't create a home directory like useradd does. So you still wind up without a directory.

You can check out my fix for this, PR #24868, which properly solves the creation of new directories for RHEL/Fedora. (I'll have to dig into why it doesn't work for Ubuntu) But that PR is blowing up on MacOSX, which I don't have access to.

That being said, it sounds like we have two bugs being discussed here. One that affects creating a home directory for an existing user, and another Ubuntu issue that has problems creating home directories, period.

RHEL output:

$ useradd -M dennis
$ ls -lZd /home/dennis
ls: cannot access /home/dennis: No such file or directory
$ usermod -d /home/dennis dennis
usermod: no changes
$ ls -lZd /home/dennis
ls: cannot access /home/dennis: No such file or directory

[lifeofguenter]

Debian 8:

$ sudo useradd -m -d /home/new_user new_user
$ ls -lZd /home/new_user/
drwxr-xr-x 2 new_user new_user ? 4096 May 22 10:35 /home/new_user/
$ sudo usermod -d /home/new_user_new_home new_user
$ ls -lZd /home/* | grep new_user
drwxr-xr-x 2 new_user new_user ? 4096 May 22 10:35 /home/new_user

$ sudo usermod -d /home/new_user new_user
$ ls -lZd /home/new_user
drwxr-xr-x 2 new_user new_user ? 4096 May 22 10:35 /home/new_user

That being said, it sounds like we have two bugs being discussed here. One that affects creating a home directory for an existing user, and another Ubuntu issue that has problems creating home directories, period.

Yup.

[rqelibari]

Thank you for your posts!
The user module creates the home directory (if it does not exist) at the lines 2223 to 2228.
Because it creates the directory with shutil.copytree it copies the permissions of /etc/skeleton (which apparently is set to 755 or a UMASK of 022). useradd and usermod use a UMASK setting with a default value of 022. According to [the manpage] this setting can be changed in /etc/login.defs.
In that context the problem here is not really a bug but rather a lack of a feature. The feature to determine the right UMASK and SELinux type.

Comment on #24868
The PR #24868 of @chriskarel seems to be a move in the right direction. Though I think the permission and selinux type values should not be hardcoded but rather an option of the module.
You will find a comment on your PR for that.

In accordance to @chriskarel s PR I propose to extend the user module with the following two options such that it acts more like the useradd tool:

• About the permissions:
  A option umask with a default value of the UMASK setting in /etc/login.defs.

• About the SELinux type user_home_t:
  A option setype with a default value of user_home_t.
  Question: Where are SELinux types actually defined? Is there a place to retrieve the default type for
  user home directories?

[lifeofguenter]

thanks @rqelibari for the investigation, however, my issue is not the permissions of the home-dir (chmod) but the owner of the created home-dir being root:root (chown).

I believe this is a regression as it worked in previous versions (<2.3)?

[rqelibari]

@lifeofguenter Yes indeed, your problem seems very odd...I cannot find a clue in the code of the user module why this could possibly happen. Especially as sudo useradd seems to work on the command line.

I will setup an Ubuntu VM later/tonight and will take a look myself on that.

[ansibot]

cc @sfromm
click here for bot help

[gentili]

Any progress on this? I've just hit it with my Ubuntu 16.04 VMs

[murarisumit]

facing this on ubuntu 16.04 VM any way to fix this ??

[ArseniiPetrovich]

Facing it too.

[ansibot]

cc @samdoran
click here for bot help

[maxamillion]

ping @rqelibari @alikins - any update on this?

[samdoran]

@gentili @murarisumit @ArseniiPetrovich There are two issues being discussed in this issue:

1. Incorrect permissions and SELinux context when changing the home dir of an existing user
2. Incorrect ownership when changing the home dir of an existing user.

I'm able to duplicate 1 on CentOS 7. I am not able to duplicate 2 on Ubuntu 1604.

If someone has a simple reproducer for 2 that is different than the original, please share so I can further troubleshoot this.

[AndrewCi]

Any idea when this is getting fixed?

[arronax]

Using ansible 2.8.4 and targeting CentOS 7 or Ubuntu 16.04, I cannot reproduce following issues:

1. Incorrect permissions when changing the home dir of an existing user
2. Incorrect ownership when changing the home dir of an existing user.

Issue with SELinux context remains on CentOS. Tested all of this using a rather simple playbook.

  tasks:
    - name: create a user without a home directory
      user:
        name: ansibletest
        create_home: no

    - name: create a home directory for the user
      user:
        name: ansibletest
        home: /home/ansibletest

    - name: create a user with a home directory
      user:
        name: ansibletesthome

    - name: change the home directory of a user
      user:
        name: ansibletesthome
        home: /home/ansibletesthomenew

Result is

# ls -laZ
drwxr-xr-x. root            root            system_u:object_r:home_root_t:s0 .
dr-xr-xr-x. root            root            system_u:object_r:root_t:s0      ..
drwx------. ansibletest     ansibletest     unconfined_u:object_r:home_root_t:s0 ansibletest
drwx------. ansibletesthome ansibletesthome unconfined_u:object_r:user_home_dir_t:s0 ansibletesthome
drwx------. ansibletesthome ansibletesthome unconfined_u:object_r:home_root_t:s0 ansibletesthomenew
drwx------. centos          centos          unconfined_u:object_r:user_home_dir_t:s0 centos

When a user is created with create_home: yes, its home directory has type user_home_dir_t, whereas changing or adding user's home directory results in its type being home_root_t.

[FF186]

Version: ansible 2.9.9

I get this bug when I run ansible module user and running sudo useradd Test1 -m.

[atar-axis]

Experienced that problem today too. Is there any workaround?

[atar-axis]

Okay i actually found the issue in my script, I used the lineinfile module for a file inside the home directory which was not yet created... afterwards I created the home directory resulting in that error.

[captainfalcon23]

Any movement on this issue? Ran into this issue on Centos7, when creating new users OR creating a new home dir for existing users, the selinux contexts aren't set correctly:

- name: Configure Linux Users - Add user accounts if hostname does contain admin
  user:
    name: "{{ item.0.username }}"
    password: "{{ item.0.password_hash }}"
    groups: "{{ item.1.groups }}"
    state: "present"
    createhome: yes
    home: "/mnt/data/{{ item.0.username }}"
  when: ansible_hostname is match(item.1.host_match) and 'admin' in ansible_hostname
  loop: "{{ linux_users_accounts | subelements('host_configs') }}"

When I try "useradd" manually, it actually throws an error when trying to create the home dir in some location which is not /home:

useradd: cannot set SELinux context for home directory /mnt/data/XXX

Looks related to: https://bugzilla.redhat.com/show_bug.cgi?id=1013968

So I assume ansible should handle this scenario, potentially by automatically applying the correct selinux perms?

[jborean93]

Can this specific issue still be replicated on the latest Ansible versions and if so can someone share the reproducer for this problem.

[gsauthof]

FWIW, using Ansible 2.16.2 from Fedora 39 (host+target), the situation improved, but I can still reproduce some of the described SELinux issues.

---

What previously didn't work but now works: Home directory of a new user has the correct SELinux label when it's created like this:

- name: add juser user
  user:
      name: juser

Previously, I had to work around incorrect labeling via a follow-up task like this:

- name: make sure home has right label                                                 
  file:                                                                                
      path: /home/juser
      owner: juser
      group: 
      mode: "0700"
      setype: _default                                                                 
      seuser: _default

---

What still doesn't work properly is the labeling when the home is created of an already existing user.

Reproducer:

$ cat blah.yml 

- hosts: all
  tasks:
      - name: adduser
        user:
            name: deletemeuser
            create_home: no
      - name: adduser2
        user:
            name: deletemeuser
            home: /home/deletemeuser

$ ansible-playbook -i root@example.org, blah.yml --diff

Result on the target:

# ls /home/deletemeuser -lZd
drwxr-xr-x. 1 deletemeuser deletemeuser system_u:object_r:etc_t:s0 94 2023-12-16 17:44 /home/deletemeuser
# ls /home/deletemeuser -lZa   
total 20
drwxr-xr-x. 1 deletemeuser deletemeuser system_u:object_r:etc_t:s0        94 2023-12-16 17:44 .
drwxr-xr-x. 1 root         root         system_u:object_r:home_root_t:s0 116 2024-03-07 19:34 ..
-rw-r--r--. 1 deletemeuser deletemeuser system_u:object_r:etc_t:s0        18 2024-01-22 01:00 .bash_logout
-rw-r--r--. 1 deletemeuser deletemeuser system_u:object_r:etc_t:s0       144 2024-01-22 01:00 .bash_profile
-rw-r--r--. 1 deletemeuser deletemeuser system_u:object_r:etc_t:s0       522 2024-01-22 01:00 .bashrc
-rw-r--r--. 1 deletemeuser deletemeuser system_u:object_r:etc_t:s0       299 2024-01-17 01:00 .zprofile
-rw-r--r--. 1 deletemeuser deletemeuser system_u:object_r:etc_t:s0       658 2024-01-17 01:00 .zshrc

Expected result: The home directory is labeled like this: unconfined_u:object_r:user_home_dir_t:s0
And its initial files are labeled like this: unconfined_u:object_r:user_home_t:s0

IOW, a follow-up restorecon -rv /home/deletemeuser should be completely silent.

Instead, in my environment, it prints:

Relabeled /home/deletemeuser from system_u:object_r:etc_t:s0 to system_u:object_r:user_home_dir_t:s0
Relabeled /home/deletemeuser/.bash_logout from system_u:object_r:etc_t:s0 to system_u:object_r:user_home_t:s0
Relabeled /home/deletemeuser/.zshrc from system_u:object_r:etc_t:s0 to system_u:object_r:user_home_t:s0
Relabeled /home/deletemeuser/.zprofile from system_u:object_r:etc_t:s0 to system_u:object_r:user_home_t:s0
Relabeled /home/deletemeuser/.bash_profile from system_u:object_r:etc_t:s0 to system_u:object_r:user_home_t:s0
Relabeled /home/deletemeuser/.bashrc from system_u:object_r:etc_t:s0 to system_u:object_r:user_home_t:s0