Un rechazo de acceso en Linux no siempre proviene de un chmod olvidado. El comando que falla puede ejecutarse con otro UID, o su cuenta no pertenece al grupo esperado. Antes de modificar un propietario, comience por identificar la cuenta realmente utilizada.
El comando id muestra el UID, el grupo principal y los grupos secundarios del proceso en curso. Es el punto de partida cuando un script, un servicio o una sesión SSH no ven el mismo archivo que usted.
Leer el UID, el GID y los grupos con id
Ejecútelo id sin argumentos en la sesión que presenta problemas:
idUna salida como uid=1000(alex) gid=1000(alex) groups=1000(alex),27(sudo),999(docker) describe la identidad del proceso. uid es el identificador de usuario. gid es el grupo principal. groups añade los grupos secundarios, a menudo aquellos que abren acceso a Docker, a los registros o a un recurso compartido.
Para recuperar solamente un valor, use las siguientes opciones:
id -umuestra el UID efectivo.id -gmuestra el GID efectivo.id -Gnlista los nombres de los grupos.id -unmuestra el nombre de la cuenta efectiva.
La diferencia entre el identificador real y el efectivo aparece sobre todo después de sudo, en un binario SUID o con ciertas herramientas que cambian de usuario. Para una verificación rápida del nombre solo, consulte también nuestro artículo sobre whoami y el usuario efectivo.
Inspeccionar una cuenta sin abrir su sesión
Agregue el nombre de la cuenta para interrogar su ficha local. Este comando lee la base de usuarios y no lo conecta bajo esta cuenta:
id www-data
id -Gn www-dataEn Debian y Ubuntu, www-data es a menudo la cuenta de los servicios web. En otra distribución, el servicio puede usar apache, nginx o una cuenta de aplicación. Verifique el archivo de unidad o la configuración del servicio en lugar de repetir este ejemplo tal cual.
Después de haber agregado un usuario a un grupo, una sesión ya abierta puede conservar su antigua lista de grupos. Desconéctese y luego vuelva a conectarse antes de concluir que la modificación ha fallado. El comando id usuario vuelve a leer la base, pero id solo describe siempre su proceso actual.
Comparar la identidad de la cuenta y los derechos del archivo
Conocer los grupos no es suficiente. Primero, hay que leer el propietario, el grupo y los permisos del camino correspondiente:
id
stat -c '%U %G %A %n' /chemin/vers/le/fichier
namei -l /chemin/vers/le/fichierstat indica a quién pertenece el archivo. namei -l también muestra los derechos de cada directorio del camino. Un archivo legible no sirve de nada si la cuenta no puede atravesar la carpeta padre, lo que requiere derecho x sobre este directorio.
No corrija un rechazo con chmod 777. Compare primero el grupo del archivo con id -Gn, luego ajuste el propietario, el grupo o los derechos necesarios. Para revisar los grupos y sus usos, lea la gestión de grupos en Linux. Si necesita modificar los permisos, nuestra guía sobre chmod recursivo explica por qué un comando demasiado amplio puede afectar muchos más archivos de lo previsto.
Probar bajo la cuenta afectada antes de modificar sudo
Cuando tenga derechos de administración, ejecute únicamente el control bajo la cuenta que presenta el problema:
sudo -u www-data id
sudo -u www-data test -r /chemin/vers/le/fichier && echo legible
sudo -u www-data test -x /chemin/vers/le/dossier && echo transitableLa primera llamada confirma la identidad efectiva. Las dos siguientes responden a una pregunta concreta, lectura del archivo o atravesar la carpeta. Reemplace www-data y las rutas antes de ejecutar. No use sudo -u para iniciar una aplicación de producción solo para probar sus derechos.
Si el acceso sigue siendo denegado aunque el UID, el grupo y los permisos Unix parecen correctos, verifique también las ACL con getfacl, los montajes de red y SELinux o AppArmor según su distribución. Estos mecanismos pueden agregar una regla por encima de los derechos clásicos.
Con id, stat y una prueba bajo la cuenta correcta, sabe dónde buscar antes de modificar derechos a ciegas.