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 actual. Es el punto de partida cuando un script, un servicio o una sesión SSH no ve el mismo archivo que usted.
Leer el UID, el GID y los grupos con id
Ejecute 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 otorgan acceso a Docker, a los registros o a un compartido.
Para recuperar solo 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 se observa 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 consultar su ficha local. Este comando lee la base de usuarios y no le conecta bajo esta cuenta:
id www-data
id -Gn www-dataEn Debian y Ubuntu, www-data suele ser 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 tomar este ejemplo tal cual.
Después de haber añadido 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. Luego 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 el 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 debe modificar los permisos, nuestra guía sobre chmod recursivo explica por qué un comando demasiado amplio puede afectar a muchos más archivos de los previstos.
Probar bajo la cuenta afectada antes de modificar sudo
Cuando tiene derechos de administración, ejecute solo 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 accesibleLa primera llamada confirma la identidad efectiva. Las dos siguientes responden a una pregunta específica, lectura del archivo o atravesamiento de la carpeta. Reemplace www-data y los caminos antes de la ejecución. No use sudo -u para lanzar una aplicación de producción solo para probar sus derechos.
Si el acceso sigue rechazado aunque UID, grupo y 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 añadir 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.