Nous utilisons SSSD pour authentifier les utilisateurs sur les serveurs CentOS. oddjobd-mkhomedir fonctionne parfaitement bien lorsque le répertoire de base par défaut est / home, mais sur un serveur particulier, nous avons dû remplacer le répertoire de base par défaut par / data, qui se trouve sur un montage SAN.
Désormais, chaque fois qu'un utilisateur tente de se connecter, il est déposé dans un shell bash avec le message suivant.
Creating home directory for first.last.
Could not chdir to home directory /data/X.Y.local/first.last: No such file or directory
-bash-4.1$
Je vois le message de refus AVC suivant pour chaque tentative:
type=AVC msg=audit(1492004159.114:1428): avc: denied { create } for pid=2832
comm="mkhomedir" name="x.y.local"
scontext=system_u:system_r:oddjob_mkhomedir_t:s0-s0:c0.c1023
tcontext=system_u:object_r:default_t:s0 tclass=dir
J'ai veillé à changer le contexte de / data.
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 data
Si / data a le même contexte que / home, pourquoi SELinux restreint-il oddjobd pour créer /data/XYlocal/first.last?
# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
[MISE À JOUR]
Je ne sais pas si c'est la bonne façon de résoudre ce problème, mais après avoir ajouté les trois entrées suivantes, l'utilisateur peut maintenant se connecter et accéder à ses répertoires personnels. Pour les nouveaux utilisateurs, les répertoires sont créés en fonction du contexte défini ci-dessous.
semanage fcontext -a -t home_root_t /data
semanage fcontext -a -t user_home_dir_t /data/x.y.local
semanage fcontext -a -t user_home_t "/data/x.y.local(/.*)?"
Est-ce la bonne façon de contourner ce problème?