Estoy usando un servicio local de contenedores de Samba que funciona con Podman 1.6.4 en un servidor CentOS 8.2.
Un servidor CentOS 8.2:
[moore@neuralux stackdata]$ cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)
Running Kernel:
[moore@neuralux stackdata]$ uname -a
Linux neuralux.lan.moore.com 4.18.0-193.19.1.el8_2.x86_64 #1 SMP Sat Sep 12 14:37:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Funciona bien, porque fui bloqueado por un archivo que no se puede escribir con Samba:
Unable to save /Volumes/git/stackdata/name.html
Error: Permission denied
Estaba usando el editor de texto Sublime para acceder a este archivo compartido en la red por Samba.
Vamos a depurar en el servidor, primero, la lista de todos los derechos de los archivos html, los permisos, el usuario y el grupo son buenos:
[moore@neuralux stackdata]$ ls -la *.html
-rw-rw-r--. 1 moore moore 165 Sep 9 21:09 about.html
-rw-rw-r--. 1 moore moore 825 Oct 4 15:38 name.html
-rw-rw-r--. 1 moore moore 763 Sep 9 21:09 search.html
No hay ningún atributo no escrito:
[moore@neuralux stackdata]$ lsattr *.html
-------------------- about.html
-------------------- name.html
-------------------- search.html
Revisemos ahora los contextos de SELinux:
[moore@neuralux stackdata]$ ls -laZ *.html
-rw-rw-r--. 1 moore moore unconfined_u:object_r:samba_share_t:s0 165 Sep 9 21:09 about.html
-rw-rw-r--. 1 moore moore unconfined_u:object_r:user_tmp_t:s0 825 Oct 4 15:38 name.html
-rw-rw-r--. 1 moore moore unconfined_u:object_r:samba_share_t:s0 763 Sep 9 21:09 search.html
El problema viene de aquí, ahora recuerdo que he hecho una copia de un archivo que viene de la carpeta /tmp que debería haber usado el contexto de seguridad por defecto “user_tmp_t”.
Comprueba que SELinux está efectivamente habilitado en este sistema:
[moore@neuralux stackdata]$ getenforce
Enforcing
[moore@neuralux stackdata]$ grep SELINUX= /etc/selinux/config
# SELINUX= can take one of these three values:
SELINUX=enforcing
Estaba usando el editor de texto Sublime para acceder a este archivo compartido en la red por Samba.
Vamos a depurar en el servidor, primero, la lista de todos los derechos de los archivos html, los permisos, el usuario y el grupo son buenos:
[moore@neuralux stackdata]$ ls -la *.html
-rw-rw-r--. 1 moore moore 165 Sep 9 21:09 about.html
-rw-rw-r--. 1 moore moore 825 Oct 4 15:38 name.html
-rw-rw-r--. 1 moore moore 763 Sep 9 21:09 search.html
No hay ningún atributo no escrito:
[moore@neuralux stackdata]$ lsattr *.html
-------------------- about.html
-------------------- name.html
-------------------- search.html
Revisemos ahora los contextos de SELinux:
[moore@neuralux stackdata]$ ls -laZ *.html
-rw-rw-r--. 1 moore moore unconfined_u:object_r:samba_share_t:s0 165 Sep 9 21:09 about.html
-rw-rw-r--. 1 moore moore unconfined_u:object_r:user_tmp_t:s0 825 Oct 4 15:38 name.html
-rw-rw-r--. 1 moore moore unconfined_u:object_r:samba_share_t:s0 763 Sep 9 21:09 search.html
El problema viene de aquí, ahora recuerdo que he hecho una copia de un archivo que viene de la carpeta /tmp que debería haber usado el contexto de seguridad por defecto “user_tmp_t”.
Comprueba que SELinux está efectivamente habilitado en este sistema:
[moore@neuralux stackdata]$ getenforce
Aplicación de la ley
[moore@neuralux stackdata]$ grep SELINUX= /etc/selinux/config
# SELINUX= puede tomar uno de estos tres valores:
SELINUX=forzar
Tenemos que ejecutar el comando “semanage fcontext -a -t samba_share_t” a nuestro archivo para cambiar el tipo a samba_share_t. La opción -a añade un nuevo registro, y la opción -t define un tipo (samba_share_t). Este comando no cambia directamente el tipo:
[moore@neuralux stackdata]$ sudo semanage fcontext -a -t samba_share_t /opt/git/stackdata/name.html
El comando semanage fcontext añade una entrada a /etc/selinux/targeted/contexts/files/file_contexts.local:
[moore@neuralux stackdata]$ sudo cat /etc/selinux/targeted/contexts/files/file_contexts.local
# This file is auto-generated by libsemanage
# Do not edit directly.
/opt/git/stackdata/name.html system_u:object_r:samba_share_t:s0
Cambie el tipo con el comando restorecon:
[moore@neuralux stackdata]$ restorecon -v name.html
Relabeled /opt/git/stackdata/name.html from unconfined_u:object_r:user_tmp_t:s0 to unconfined_u:object_r:samba_share_t:s0
Comprueba el nuevo contexto de seguridad:
[moore@neuralux stackdata]$ ls -Zla *.html
-rw-rw-r--. 1 moore moore unconfined_u:object_r:samba_share_t:s0 165 Sep 9 21:09 about.html
-rw-rw-r--. 1 moore moore unconfined_u:object_r:samba_share_t:s0 825 Oct 4 15:51 name.html
-rw-rw-r--. 1 moore moore unconfined_u:object_r:samba_share_t:s0 763 Sep 9 21:09 search.html
Problema arreglado Samba ahora puede escribir este archivo sin errores.