Bug 1077809

Summary:	useradd not assigning correct SELinux user to contexts of home directory files
Product:	Red Hat Enterprise Linux 7	Reporter:	Tomas Mraz <tmraz>
Component:	shadow-utils	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED ERRATA	QA Contact:	Stanislav Zidek <szidek>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	mgrepl, szidek, tmraz
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	shadow-utils-4.1.5.1-15.el7	Doc Type:	Bug Fix
Doc Text:	Cause: The useradd assigned the SELinux user to the new user being created after creating and populating the home directory of the user. Consequence: The SELinux contexts of the home directory files were incorrect. Fix: The SELinux user is assigned to the newly created user before populating the home directory. Result: The SELinux contexts on the home directory files for newly created users are now correct.	Story Points:	---
Clone Of:	955769	Environment:
Last Closed:	2014-09-15 11:13:48 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1110706

Description Tomas Mraz 2014-03-18 15:40:03 UTC

This bug applies to RHEL-7 as well.

+++ This bug was initially created as a clone of Bug #955769 +++

Description of problem:
Users created using useradd -Z are not given the correct user in the context of their home directory

Version-Release number of selected component (if applicable):
shadow-utils-4.1.4.2-13.el6.x86_64
possibly,
policycoreutils-python-2.0.8-19.30.el6_64

How reproducible:
Easily

Steps to Reproduce:
1.Switch to root
2.useradd -m testuser -Z staff_u
3.ls -Z /home/testuser 
  
Actual results:
drwx------. testuser testuser unconfined_u:object_r:user_home_dir_t:s0 .
drwxr-xr-x. root     root     system_u:object_r:home_root_t:s0 ..
-rw-r--r--. testuser testuser unconfined_u:object_r:user_home_t:s0 .bash_logout
-rw-r--r--. testuser testuser unconfined_u:object_r:user_home_t:s0 .bash_profile
-rw-r--r--. testuser testuser unconfined_u:object_r:user_home_t:s0 .bashrc
-rw-r--r--. testuser testuser unconfined_u:object_r:user_home_t:s0 .emacs
drwxr-xr-x. testuser testuser unconfined_u:object_r:gnome_home_t:s0 .gnome2
drwxr-xr-x. testuser testuser unconfined_u:object_r:mozilla_home_t:s0 .mozilla

Expected results:
ls -Za /home/testuser
drwx------. testuser testuser staff_u:object_r:user_home_dir_t:s0 .
drwxr-xr-x. root     root     system_u:object_r:home_root_t:s0 ..
-rw-r--r--. testuser testuser staff_u:object_r:user_home_t:s0 .bash_logout
-rw-r--r--. testuser testuser staff_u:object_r:user_home_t:s0 .bash_profile
-rw-r--r--. testuser testuser staff_u:object_r:user_home_t:s0 .bashrc
-rw-r--r--. testuser testuser staff_u:object_r:user_home_t:s0 .emacs
drwxr-xr-x. testuser testuser staff_u:object_r:gnome_home_t:s0 .gnome2
drwxr-xr-x. testuser testuser staff_u:object_r:mozilla_home_t:s0 .mozilla

Additional info:
If you run restorecon, the context is updated correctly
[root@owf SPECS]# restorecon -RF /home/testuser
[root@owf SPECS]# ls -Za /home/testuser
drwx------. testuser testuser staff_u:object_r:user_home_dir_t:s0 .
drwxr-xr-x. root     root     system_u:object_r:home_root_t:s0 ..
-rw-r--r--. testuser testuser staff_u:object_r:user_home_t:s0  .bash_logout
-rw-r--r--. testuser testuser staff_u:object_r:user_home_t:s0  .bash_profile
-rw-r--r--. testuser testuser staff_u:object_r:user_home_t:s0  .bashrc
-rw-r--r--. testuser testuser staff_u:object_r:user_home_t:s0  .emacs
drwxr-xr-x. testuser testuser staff_u:object_r:gnome_home_t:s0 .gnome2
drwxr-xr-x. testuser testuser staff_u:object_r:mozilla_home_t:s0 .mozilla

I've tested this on F18 and it's there as well. Looking at the code in useradd.c what is happening is that all of the files in a users home directories are written out before the SELinux user mappings are updated. So the system is using the default mapping of unconfined_u to write it out. There seem to be 2 quick fixes
1) Run restorecon -RF following the calls to semanage in useradd.c
2) Update semanage to have a flag to check if files need to be relabeled after adding a login mapping and update them.

Comment 1 Tomas Mraz 2014-08-27 14:18:16 UTC

*** Bug 1134450 has been marked as a duplicate of this bug. ***

Comment 5 Tomas Mraz 2014-09-09 14:20:27 UTC

Mirek, do you have any idea what could be wrong here? semanage_commit() is called and only then the home dir is created and files copied. If the semanage login entry is present before running useradd, the contexts are correct.

On RHEL-6 where the code is the same except semanage command is used instead of libsemanage calls, it works correctly.

Comment 6 Tomas Mraz 2014-09-10 08:39:37 UTC

It seems that adding matchpathcon_fini() after semanage_commit() fixes this.

Comment 10 errata-xmlrpc 2014-09-15 11:13:48 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1191.html