4
[root@tst-01 home]# ls -Z
drwxr-xr-x. ujjain   users          system_u:object_r:home_root_t:s0 ujjain
drwxr-xr-x. johndoe   users          system_u:object_r:home_root_t:s0 johndoe

The selinux context should be object_r:user_home_dir_t. 

[root@tst-01 ~]# sesearch -T -t home_root_t
Found 10 semantic te rules:
   type_transition oddjob_mkhomedir_t home_root_t : dir user_home_dir_t;
   type_transition automount_t home_root_t : dir automount_tmp_t;
   type_transition lsassd_t home_root_t : dir user_home_dir_t;
   type_transition useradd_t home_root_t : dir user_home_dir_t;
   type_transition firstboot_t home_root_t : dir user_home_dir_t;
   type_transition smbd_t home_root_t : dir user_home_dir_t;
   type_transition quota_t home_root_t : file quota_db_t;
   type_transition sysadm_t home_root_t : dir user_home_dir_t;
   type_transition cups_pdf_t home_root_t : dir user_home_dir_t;
   type_transition postfix_virtual_t home_root_t : dir user_home_dir_t;

[root@tst-01 ~]#

New home-directories are created with the wrong Selinux context. I can fix the selinux context with chcon, but this creates problems on multiple servers.

What can be the reason the context was set wrong in the first place?

ujjain
  • 3,983
  • 16
  • 53
  • 91

3 Answers3

11

Adding to this question for future people who may come across it. If you are putting home directories on an NFS share, you will need to set the correct SELinux context. Assuming your nfs home directory is /nfshome, do the following:

[root@host /]# semanage fcontext -a -e /home /nfshome
[root@host /]# restorecon -vR /nfshome
Python Novice
  • 351
  • 1
  • 5
  • 13
  • Thank you, this is exactly what I needed. This should be a FAQ for *any* home directory not in /home/ (e.g. mine were in /data/). – Aaron D. Marasco Feb 13 '17 at 16:40
  • This worked for me -- the first `semanage ...` line marks the /nfshome directory as having the same selinux context as the standard /home directory, and the second line verbosely and Recursively restores the security contexts of the /nfshome directory. I used it on a non-nfs /local/home dir. What I liked about it was not having to determine and explicitly set the contexts, but I just matched the contexts of a working, existing dir. – Dave X Jul 09 '18 at 22:48
6

In the case of user's $HOME directories, usually in /home/$USER, you don't need to use chcon, which changes the security context of files and directories, in the sense of diverting them from the policy, and, for what is worth, won't survive a system relabel. Rather, you need to find out what is the expected security context of the directories:

# matchpathcon /home/ujjain
# matchpathcon /home/johndoe

And if the context doesn't match the output of ls -lrtZ, restore the context:

# restorecon -v /home/ujjain
# restorecon -v /home/johndoe

Note that restorecon can be used recursively -R.

Regarding your question, the reason why this directories have a wrong label depends on the procedure used to create them (which you didn't specify) and the location of the /home directory (local filesystem vs. NFS, for example)

dawud
  • 15,096
  • 3
  • 42
  • 61
4

The issue appears to be here: 

[root@tst-01 ~]# grep homedir /etc/pam.d/system-auth
session     optional      pam_mkhomedir.so skel=/etc/skel

Since the pam stack should not be making homedirs, the odd job module should be used to do the heavy lifting instead with the pam_oddjob_mkhomedir module since it requires fewer permissions and works well with SELinux.

ujjain
  • 3,983
  • 16
  • 53
  • 91