Corregir permisos en lote: tomar propiedad sin romper la herencia

Entender qué significa realmente “herencia” en Linux

La gente dice “herencia” como si fuera una propiedad universal de los permisos. No lo es. En Linux, la herencia es un comportamiento emergente creado por unos cuantos mecanismos separados:

1) Los bits de modo POSIX (chmod) no heredan

Los directorios tienen permisos; los archivos tienen permisos. Crear un archivo nuevo dentro de un directorio no “hereda” los bits de modo del directorio padre. El archivo nuevo obtiene un modo basado en el proceso que lo crea y su umask, no en el rwx del directorio padre.

2) El bit setgid en directorios es una herencia de grupo (más o menos)

Si un directorio tiene el bit setgid (chmod g+s), los archivos y subdirectorios creados dentro normalmente heredan la propiedad de grupo del directorio. Esta es la herramienta clásica y sorprendentemente efectiva para carpetas de equipo compartidas.

3) Las ACL POSIX proveen herencia real mediante “ACL por defecto”

Las ACL te dan usuarios/grupos nombrados, máscaras y valores por defecto. Un directorio puede tener entradas de ACL por defecto que se aplican a los objetos nuevos creados dentro. Eso es lo más cercano a la herencia estilo Windows que obtienes en el mundo POSIX nativo.

4) “Tomar propiedad” es una decisión de política, no solo un comando

Cuando ejecutas chown, cambias quién puede modificar permisos, quién puede cambiar ACLs y quién es efectivamente responsable. Bien hecho, restaura el orden. Mal hecho, es un golpe silencioso.

5) La máscara de la ACL es el asesino silencioso

En sistemas que usan ACL POSIX, la entrada mask puede restringir los permisos efectivos para usuarios y grupos nombrados. Así que puedes “conceder” acceso y aún ver Permission denied porque la máscara lo limita. Así es como ingenieros sensatos pierden una tarde entera.

Una idea parafraseada de un lumbrera de confiabilidad encaja aquí: idea parafraseada — “Todo falla; diseña para que las fallas sean predecibles y recuperables.” — Richard Cook (parafraseado)

Hechos e historia interesantes que puedes usar en argumentos

• Hecho 1: Los permisos tradicionales de Unix (owner/group/other) datan de los primeros Unix en los años 70, optimizados por simplicidad más que por expresividad.
• Hecho 2: Los bits setuid/setgid/sticky no fueron tanto “funciones de seguridad” como trucos pragmáticos para sistemas multiusuario que necesitaban flujos de trabajo compartidos.
• Hecho 3: Las ACL POSIX se generalizaron en Linux a inicios de los 2000 cuando las empresas demandaron control de acceso más granular que los bits de modo.
• Hecho 4: La entrada de ACL mask existe para proporcionar un techo en los permisos efectivos—genial para el control, terrible para la intuición.
• Hecho 5: En muchos sistemas de archivos Linux, el soporte de ACL está integrado, pero aún necesitas herramientas de userland (getfacl, setfacl) para gestionarlo de forma sensata.
• Hecho 6: SMB/CIFS (Samba) a menudo mapea la semántica de ACL de Windows a ACL POSIX o atributos extendidos, lo que puede verse “correcto” en Windows y “extraño” en Linux.
• Hecho 7: NFS ha tenido múltiples modelos de seguridad a través de sus versiones; lo que “funciona” en NFSv3 con mapeo de UID puede romperse espectacularmente cuando cambias la gestión de identidades.
• Hecho 8: rsync puede preservar propiedad, bits de modo, xattrs y ACLs—pero solo si lo pides explícitamente y el destino lo soporta.
• Hecho 9: El sticky bit en directorios (como /tmp) es un mecanismo de seguridad multiusuario simple pero poderoso: puedes crear archivos, pero no borrar los de otros.

Guía de diagnóstico rápido (encuentra el cuello de botella)

Esta es la secuencia de “deja de adivinar”. Ejecútala en orden. Reduce el problema a identidad, sistema de archivos, semántica de ACL o herramientas.

Primero: identifica la ruta de acceso y la traducción de identidad

1. ¿Desde dónde se accede? shell local, SSH, Samba, NFS, bind mount en contenedor?
2. ¿Quién es el usuario? el UID/GID numérico importa más que los nombres en muchos modos de falla.
3. ¿Hay un desajuste de identidad? cambios en AD/LDAP/SSSD, idmap, problemas de idmapping en NFS.

Segundo: comprueba los permisos efectivos en el punto de fallo

1. Bit de ejecución del directorio (x) en cada segmento del path padre.
2. Entradas de ACL POSIX y la máscara de ACL.
3. Opciones de montaje (por ejemplo, noacl, nosuid, root squashing en NFS).

Tercero: decide si vas a arreglar propiedad, ACLs o ambos

1. Si la propiedad está mal pero las ACLs están bien, prefiere chown dirigido.
2. Si faltan los valores por defecto de ACL, corrige las ACL por defecto del directorio, no cada archivo.
3. Si el modelo es inconsistente, haz snapshot/backup de los metadatos y reconstruye desde una política conocida.

Broma 1: Si tu modelo de permisos requiere una presentación de 40 diapositivas, no es un modelo. Es una situación de rehenes.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las tareas que realmente ejecuto durante incidentes y migraciones. Cada una incluye qué significa la salida y qué decisión tomar a partir de ella.

Tarea 1: Confirma tipo de sistema de archivos y opciones de montaje (las ACL pueden estar deshabilitadas)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /srv/share
/dev/sdb1 /srv/share ext4 rw,relatime,errors=remount-ro

Significado: Estás en ext4 con opciones normales. Si vieras noacl (o un montaje NFS sin las características esperadas), esperarías un comportamiento de ACL distinto.

Decisión: Si las opciones de montaje chocan con tu estrategia de permisos, arregla la configuración de montaje antes de tocar permisos. Si no, “arreglarás” metadatos que el kernel ignora.

Tarea 2: Reproduce como el usuario afectado y captura el fallo exacto

cr0x@server:~$ sudo -u alice bash -lc 'cd /srv/share/team && touch testfile'
touch: cannot touch 'testfile': Permission denied

Significado: Esto es una falla de escritura/creación, no de lectura. En directorios, crear requiere w y x en el directorio.

Decisión: Enfócate en permisos/ACLs del directorio, no en los permisos de archivo. Puedes chmod archivos para siempre; la creación seguirá fallando.

Tarea 3: Revisa identidad numérica y pertenencia a grupos (los nombres pueden mentir)

cr0x@server:~$ id alice
uid=10501(alice) gid=10501(alice) groups=10501(alice),12000(finance),12010(shared-team)

Significado: Alice pertenece a shared-team. Si no lo hiciera, tu “problema de permisos” podría ser una cuestión de aprovisionamiento de identidad/grupo.

Decisión: Si falta la pertenencia a grupo, corrige IAM/LDAP/AD/SSSD primero. No enmascares identidad con ACLs permisivas.

Tarea 4: Inspecciona los bits de modo del directorio (¿tenemos ejecución?)

cr0x@server:~$ namei -l /srv/share/team
f: /srv/share/team
drwxr-xr-x root root /
drwxr-xr-x root root srv
drwxr-x--- root shared-team share
drwxrwx--- root shared-team team

Significado: El path parece accesible para el grupo en /srv/share y /srv/share/team. Si algún padre careciera de x para la clase relevante, la traversía fallaría.

Decisión: Si la traversía falla, arregla el directorio padre primero. Una ACL perfecta en la hoja no servirá si no puedes alcanzarla.

Tarea 5: Comprueba ACLs y la máscara en el directorio

cr0x@server:~$ getfacl -p /srv/share/team
# file: /srv/share/team
# owner: root
# group: shared-team
user::rwx
group::rwx
other::---
mask::r-x
default:user::rwx
default:group::rwx
default:other::---

Significado: El mask::r-x limita los permisos de grupo a lectura/ejecución aunque exista group::rwx. Eso puede bloquear escrituras.

Decisión: Arregla la máscara (setfacl -m m::rwx) o reaplica entradas de ACL con manejo correcto de la máscara. No añadas usuarios a ciegas; aún estarás bloqueado.

Tarea 6: Muestra permisos efectivos de ACL (evita autoengaños)

cr0x@server:~$ getfacl -p /srv/share/team | sed -n '1,20p'
# file: /srv/share/team
# owner: root
# group: shared-team
user::rwx
group::rwx              #effective:r-x
other::---
mask::r-x
default:user::rwx

Significado: La anotación #effective te dice la verdad: el grupo es efectivamente r-x, no rwx.

Decisión: Si los permisos efectivos no coinciden con la intención, trata la máscara como un control de configuración de primera clase, no como una ocurrencia tardía.

Tarea 7: Arregla solo la máscara de ACL del directorio (cambio quirúrgico)

cr0x@server:~$ setfacl -m m::rwx /srv/share/team
cr0x@server:~$ getfacl -p /srv/share/team | grep -E 'mask|group::'
group::rwx
mask::rwx

Significado: La máscara ahora permite escrituras. Si los usuarios aún no pueden crear archivos, el siguiente sospechoso son las ACL por defecto y el umask.

Decisión: Vuelve a probar la creación como el usuario. Si está solucionado, para. No sigas “mejorando” permisos después de resolver el incidente.

Tarea 8: Verifica las ACL por defecto (herencia para archivos nuevos)

cr0x@server:~$ getfacl -p /srv/share/team | grep -E '^default:'
default:user::rwx
default:group::rwx
default:other::---

Significado: Existe una ACL por defecto, pero puede faltar entradas nombradas para grupos requeridos, o la máscara por defecto puede ser incorrecta.

Decisión: Si necesitas que varios grupos hereden acceso, añade entradas de grupo por defecto nombradas y establece una máscara por defecto adecuada.

Tarea 9: Añade una ACL por defecto para un grupo colaborador (y mantenla heredable)

cr0x@server:~$ setfacl -m d:g:finance:rwx /srv/share/team
cr0x@server:~$ setfacl -m d:m::rwx /srv/share/team
cr0x@server:~$ getfacl -p /srv/share/team | grep -E 'default:group:finance|default:mask'
default:group:finance:rwx
default:mask::rwx

Significado: Los archivos/dirs nuevos creados bajo /srv/share/team heredarán una entrada ACL para el grupo finance, sujeta a la máscara por defecto.

Decisión: Si la herencia es el objetivo, configura siempre valores por defecto en los directorios. No apliques ACLs recursivamente a contenido existente a menos que sea necesario.

Tarea 10: Confirma setgid en el directorio (continuidad de propiedad de grupo)

cr0x@server:~$ stat -c '%A %U %G %n' /srv/share/team
drwxrwx--- root shared-team /srv/share/team

Significado: No se muestra el bit setgid (s aparecería en la posición de ejecución de grupo). Sin él, los archivos nuevos pueden obtener el grupo primario del creador, no shared-team.

Decisión: Para directorios de colaboración, habilita setgid salvo que tengas una razón de peso para no hacerlo.

Tarea 11: Habilita setgid y valida el comportamiento con un archivo de prueba

cr0x@server:~$ chmod g+s /srv/share/team
cr0x@server:~$ stat -c '%A %U %G %n' /srv/share/team
drwxrws--- root shared-team /srv/share/team
cr0x@server:~$ sudo -u alice bash -lc 'touch /srv/share/team/owned-by-group && stat -c "%U %G %n" /srv/share/team/owned-by-group'
alice shared-team /srv/share/team/owned-by-group

Significado: La propiedad de grupo ahora se mantiene consistente. Eso reduce futuros tickets “¿por qué este archivo pertenece al grupo equivocado?”.

Decisión: Mantén setgid en directorios de alta colaboración. Es aburrido. Lo aburrido es bueno.

Tarea 12: Previsualiza el radio de acción antes de un cambio recursivo de propiedad

cr0x@server:~$ find /srv/share/team -maxdepth 2 -printf '%u:%g %m %p\n' | head
root:shared-team 2770 /srv/share/team
root:shared-team 2770 /srv/share/team/projects
bob:shared-team 0660 /srv/share/team/projects/notes.txt
carol:finance 0660 /srv/share/team/projects/budget.xlsx

Significado: Tienes propiedad y grupos mixtos. Un chown -R root:shared-team a ciegas sobreescribiría patrones deliberados de propiedad por proyecto.

Decisión: Si la propiedad mixta es esperada, evita chown global. Si es accidental, define reglas (qué debe cambiar y qué debe permanecer).

Tarea 13: Cambia la propiedad de forma segura con filtros (apunta solo a lo incorrecto)

cr0x@server:~$ find /srv/share/team -group finance -print | head -n 3
/srv/share/team/projects/budget.xlsx
/srv/share/team/projects/q1
/srv/share/team/archive/old

Significado: Estos objetos tienen grupo finance. Quizá esté mal. Quizá esté bien. Ahora sabes dónde están.

Decisión: Usa predicados de find para delimitar los cambios. Tu yo futuro agradecerá la mesura.

Tarea 14: Realiza un chgrp acotado (solo grupo) y verifica una muestra

cr0x@server:~$ sudo chgrp shared-team /srv/share/team/projects/budget.xlsx
cr0x@server:~$ stat -c '%U %G %n' /srv/share/team/projects/budget.xlsx
carol shared-team /srv/share/team/projects/budget.xlsx

Significado: Grupo ajustado, propietario preservado. Eso suele ser menos arriesgado que cambiar ambos.

Decisión: Prefiere chgrp sobre chown cuando la propiedad no es el problema.

Tarea 15: Haz backup de ACLs y xattrs antes de ediciones masivas (tu plan de rollback)

cr0x@server:~$ getfacl -R -p /srv/share/team > /root/team.acl.backup
cr0x@server:~$ wc -l /root/team.acl.backup
48231 /root/team.acl.backup

Significado: Tienes un backup en texto del metadata de ACL. No es perfecto, pero es una palanca real de rollback.

Decisión: Si no puedes snapshotear, al menos captura metadata. Cambios masivos de permisos sin rollback son jugar a los dados con datos en producción.

Tarea 16: Restaura ACLs desde el backup si la fastidias

cr0x@server:~$ setfacl --restore=/root/team.acl.backup
cr0x@server:~$ echo $?
0

Significado: El código de salida 0 indica que la restauración tuvo éxito. Aún necesitas comprobaciones puntuales.

Decisión: Al restaurar, valida algunos directorios y archivos críticos. Confía, pero verifica—especialmente después de demostrar que eres falible.

Estrategia para cambios de propiedad masivos sin daño colateral

“Tomar propiedad” suele ser atajo para uno de tres objetivos:

• Control operativo: una cuenta de servicio o grupo admin debe poder reparar permisos más tarde.
• Corrección de acceso: los usuarios finales necesitan volver a leer/escribir.
• Aplicación de política: todo en un árbol debe cumplir un estándar conocido.

Esos objetivos requieren tácticas diferentes. Trátalos distinto o arreglarás el incidente y romperás tu modelo de gobernanza. Sí, ambos son malos; uno aparece en auditorías en lugar de en pagers.

Cuándo no deberías ejecutar chown -R

Un cambio recursivo de propiedad es apropiado cuando los propietarios actuales están claramente equivocados (p. ej., todo es propiedad de un UID retirado de la migración, o por root porque una restauración corrió como root). No es apropiado cuando:

• El árbol contiene varios proyectos con distintos propietarios por diseño.
• Las aplicaciones dependen de propietarios específicos para límites de seguridad.
• Las ACL ya codifican la política de acceso y la propiedad solo sirve para “quién puede chmod”.

Tomar propiedad preservando la herencia: el patrón seguro

Este es el patrón que funciona en la mayoría de configuraciones de archivos compartidos:

1. Arregla la herencia a nivel de directorio primero: setgid + ACLs por defecto + máscaras correctas.
2. Deja de usar la propiedad como control de acceso en árboles compartidos. Usa grupo + política de ACL para acceso; reserva la propiedad para control administrativo.
3. Normaliza solo lo que debe normalizarse: directorios y áreas críticas de colaboración, no archivos históricos salvo que sea necesario.
4. Valida con acciones reales de usuarios: crear, renombrar, borrar, editar. Leer es lo fácil.

Qué significa realmente “no romper la herencia”

Significa que no eliminas accidentalmente:

• entradas de ACL por defecto en directorios,
• setgid en directorios de colaboración,
• los valores de máscara de ACL previstos,
• expectativas de mapeo de Samba/NFS (IDs, xattrs),
• requisitos de permisos específicos de aplicaciones.

Broma 2: chmod 777 es como desenchufar la alarma de incendios porque hace ruido. Silencio, sí. Mejor, no.

Tres microhistorias corporativas desde las trincheras

Microhistoria 1: El incidente causado por una suposición errónea

Tenían un servidor de archivos Linux que exportaba una share por Samba. Un ingeniero nuevo—inteligente, rápido, peligrosamente optimista—supuso que la herencia estilo Windows “se almacenaba en la carpeta” y naturalmente se propagaba hacia abajo.

Durante una reorganización, crearon un nuevo directorio de nivel superior, copiaron datos y ajustaron permisos en la raíz usando un cliente Windows. En el Explorador los permisos se veían bien. Todos se fueron a casa.

A la mañana siguiente, el equipo de diseño no pudo guardar archivos. El directorio mostraba acceso “Modificar”, pero cada guardado fallaba. El ingeniero revisó la configuración del share y no encontró nada. Clásico.

El problema real: el nuevo directorio no tenía entradas POSIX ACL por defecto, y la máscara de ACL en algunos directorios era restrictiva. Archivos creados por algunas aplicaciones recibieron un modo limitado por umask y sin entradas ACL heredables. Los clientes Windows mostraban una abstracción amigable; el lado Linux hacía cumplir otra realidad.

La solución no fue reescribir ACLs recursivamente. Pusieron ACLs por defecto en los directorios correctos, corrigieron máscaras, habilitaron setgid y tocaron solo los puntos calientes donde se estaban creando archivos. La “suposición errónea” no era sobre la sintaxis. Era sobre cuál sistema era la fuente de la verdad.

Microhistoria 2: La optimización que salió mal

Un equipo de storage quiso acelerar la ingestión nocturna a un dataset compartido. Alguien propuso: “Hagamos la ingestión como root, evitará comprobaciones de permisos y será más rápido.” Funcionó. La ingestión terminó antes. Celebraron con ese tipo de satisfacción silenciosa que tienes al recortar minutos en un trabajo que nadie disfruta.

Dos semanas después, los usuarios empezaron a reportar incapacidad aleatoria para editar archivos. No era consistente: un directorio estaba bien, el siguiente no. Los tickets se volvieron hilos de Slack, luego reuniones, luego más Slack. La productividad murió a base de mil “¿puedes intentar de nuevo?”.

La causa raíz fue sutil: los archivos creados por root tenían modos y ACLs que no coincidían con el modelo de colaboración. Algunos archivos no tenían entradas nombradas de ACL, y otros tenían máscaras restrictivas por cómo los scripts aplicaban las ACLs. La ingestión fue “más rápida” porque evitó las restricciones de corrección.

El rollback no fue bonito. Tuvieron que identificar archivos creados por el usuario de ingest en un rango de fechas, restaurar la propiedad de grupo correcta y aplicar la política de ACL donde hacía falta. La lección quedó: los hacks de rendimiento que tocan identidad y permisos son un instrumento de deuda con interés compuesto.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Otra organización tenía el hábito disciplinado: antes de cualquier cambio grande de permisos, capturaban ACLs recursivamente a un archivo con timestamp y tomaban un snapshot del sistema de archivos si estaba disponible. Estaba en su plantilla de cambios y todos cumplían porque la rotación on-call era sufrimiento compartido.

Durante una migración, un script destinado a arreglar la propiedad de grupo se ejecutó accidentalmente en el mountpoint equivocado. Cambió la propiedad de grupo en una share viva usada por varios equipos. El monitoring no gritó; los problemas de permisos rara vez parecen picos de CPU. Los usuarios gritaron en su lugar, que es una señal menos amigable para máquinas.

Porque tenían el backup de ACL pre-cambio y un snapshot, la recuperación fue mecánica: remontar en solo lectura brevemente, restaurar ACLs, revertir el snapshot para el subtree afectado y luego volver a aplicar el cambio con el scope corregido. El outage no fue cero, pero estuvo acotado. Sin arqueología, sin conjeturas.

Lo que los salvó no fue heroísmo. Fue el aburrimiento: una checklist, un artefacto de rollback y la negativa a tratar “los permisos funcionan” como algo demasiado simple para necesitar medidas de seguridad.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “El usuario tiene rwx en el directorio pero aún así no puede crear archivos”

Causa raíz: La máscara de ACL limita los permisos efectivos (mask::r-x), o el usuario no tiene escritura en términos efectivos.

Solución: Inspecciona con getfacl y busca #effective. Ajusta la máscara: setfacl -m m::rwx DIR y si es necesario setfacl -m d:m::rwx DIR.

2) Síntoma: “Los archivos nuevos tienen el grupo equivocado”

Causa raíz: Falta el bit setgid en los directorios, o la aplicación crea en una ubicación distinta sin setgid.

Solución: chmod g+s DIR. Confirma con stat y prueba la creación como un usuario normal.

3) Síntoma: “Todo se ve bien en Linux, pero usuarios Windows no pueden editar”

Causa raíz: Desajuste en el mapeo de ACL de Samba, xattrs no preservados, o Windows espera semánticas de herencia que los defaults POSIX no proveen.

Solución: Valida las ACL por defecto POSIX en los directorios; asegura que el share esté configurado consistentemente; confirma soporte de xattr y que la copia/migración preservó ACLs.

4) Síntoma: “Después de chmod -R, el acceso empeoró”

Causa raíz: Los bits de modo cambiaron pero las ACLs permanecen; chmod puede interactuar con la máscara de ACL y eliminar vías de acceso previstas.

Solución: Deja de hacer chmod recursivo en árboles gestionados por ACL. Reaplica la política de ACL prevista en directorios y corrige máscaras. Restaura desde backup de ACL si lo tienes.

5) Síntoma: “Root no puede arreglarlo vía NFS”

Causa raíz: Root squashing mapea root a un UID anónimo, bloqueando cambios de propiedad.

Solución: Haz la reparación de permisos en el lado servidor (no en el montaje cliente), o ajusta la política de export NFS deliberadamente y temporalmente con control de cambios.

6) Síntoma: “Algunos directorios son escribibles; otros idénticos no lo son”

Causa raíz: ACLs por defecto inconsistentes entre directorios, a menudo por migraciones parciales o arreglos ad-hoc.

Solución: Compara con getfacl un directorio bueno y uno malo. Normaliza defaults de directorio; evita tocar archivos históricos a menos que sea necesario.

Listas de verificación / plan paso a paso

Plan paso a paso para un arreglo masivo seguro

1. Aclara el modelo: decide qué grupos/usuarios deben tener lectura/escritura y qué directorios necesitan comportamiento de herencia.
2. Captura artefactos de rollback: haz snapshot si está disponible; de lo contrario getfacl -R -p a un archivo.
3. Confirma la ruta de acceso: local vs Samba vs NFS; confirma mapeo de IDs y pertenencia a grupos.
4. Elige un subárbol piloto: una carpeta de proyecto, no todo el share.
5. Arregla la herencia en directorios: setgid + entradas ACL por defecto + máscaras por defecto.
6. Corrige máscaras de ACL de directorio: asegura que los permisos efectivos coincidan con la intención.
7. Retesta con acciones reales: crear, renombrar, borrar, editar y crear desde aplicación (no solo touch).
8. Normaliza la propiedad de grupo donde haga falta: prefiere chgrp con expresiones find acotadas.
9. Solo entonces considera operaciones recursivas: cuando puedas articular el radio de acción y tengas rollback.
10. Avanza de forma sistemática: aplica el mismo patrón de arreglo al siguiente subárbol; no improvises por directorio.
11. Documenta las reglas: expectativas de setgid, entradas ACL por defecto y la razón de las máscaras.
12. Guardarraíles: un trabajo de auditoría periódico que marque directorios sin setgid o sin ACLs por defecto.

Lista previa al cambio (imprimible en tu cabeza)

• ¿Tengo snapshot o backup de ACL?
• ¿Sé qué protocolo usan los usuarios (Samba/NFS/local)?
• ¿Reproduje como un usuario real con sudo -u?
• ¿Verifiqué la máscara de ACL y los permisos efectivos?
• ¿Estoy cambiando directorios (herencia) antes que archivos (síntomas)?
• ¿Uso find acotado en vez de -R por rutina?

Lista posterior al cambio (demuestra que está arreglado)

• Crea un archivo, un directorio y renombra ambos como un usuario afectado.
• Verifica que la propiedad de grupo de objetos nuevos coincide con lo esperado (setgid funcionando).
• Verifica que un segundo grupo colaborador puede acceder si eso está en la política (ACL por defecto funciona).
• Revisa una carpeta “sensible conocida” para asegurarte de no haber ampliado acceso.
• Mantén el backup de ACL/snapshot hasta que termine el siguiente ciclo de negocio.

Preguntas frecuentes

1) ¿Qué significa “tomar propiedad” en el contexto de una carpeta compartida?

Usualmente: establecer un propietario administrativo consistente (a menudo root o una cuenta de servicio) mientras se usan grupos/ACLs para dar acceso a usuarios. La propiedad es para control; las ACLs son para colaboración.

2) ¿Por qué a veces chmod parece “romper” permisos de ACL?

Porque ACLs y bits de modo interactúan. La máscara de ACL puede cambiar permisos efectivos, y algunas operaciones de chmod pueden alterar la máscara. Si gestionas acceso con ACLs, trata chmod como una herramienta quirúrgica, no como un hábito recursivo.

3) ¿Cómo preservo la herencia para archivos nuevos?

En Linux: usa setgid en directorios para herencia de grupo y ACLs por defecto para herencia de permisos. Verifica las entradas de máscara por defecto para que los permisos heredados sean realmente efectivos.

4) ¿Debo aplicar ACLs recursivamente a todos los archivos?

No por defecto. Arregla primero los defaults de directorio; influyen en el contenido futuro. Corregir recursivamente archivos existentes a veces es necesario tras migraciones, pero incrementa riesgo y tiempo de ejecución, y es fácil sobreexponer datos.

5) Ejecuté chown -R y ahora las apps fallan. ¿Cuál es el rollback más rápido?

Si tomaste un snapshot, reviértelo para el subtree afectado. Si no, restaura ACLs desde tu backup de getfacl y luego corrige propiedad usando reglas acotadas. Si no tienes ninguno, estás reconstruyendo la política por inferencia—presupuesta tiempo.

6) ¿Por qué un usuario puede listar un directorio pero no acceder a archivos dentro?

Listar requiere read en el directorio; acceder a un nombre concreto requiere execute en el directorio y permisos apropiados en el archivo. Falta de x en un directorio padre es un tropiezo común.

7) ¿Cuál es la diferencia entre una entrada de ACL y la máscara de ACL?

Las entradas expresan permisos deseados para usuarios/grupos. La máscara es el máximo permiso efectivo para usuarios/grupos nombrados y la clase de grupo. Si la máscara es restrictiva, las entradas no se comportarán como esperas.

8) ¿Cómo se relacionan la herencia de Samba/Windows con los defaults de ACL en Linux?

Samba puede mapear ACLs de Windows a ACLs POSIX y/o almacenar metadata más rica en xattrs. La “herencia” de Windows no siempre se traduce limpiamente. En Linux, las ACLs por defecto en directorios son el análogo más cercano para la herencia de objetos nuevos.

9) ¿Es seguro arreglar permisos mientras los usuarios están activos?

A veces. Cambios de ACL/default de directorio suelen ser seguros pero pueden causar fallos transitorios si quitas acceso brevemente. Cambios recursivos grandes incrementan riesgo y carga. Si es crítico para el negocio, haz una ventana controlada y ten rollback listo.

Conclusión: próximos pasos que deberías hacer

Si estás frente a un árbol de permisos desordenado, no empieces por la recursión. Comienza por la verdad: confirma identidad, confirma semántica de montaje, confirma ACLs efectivas (especialmente máscaras) y luego arregla la herencia a nivel de directorio. Ahí es donde radica la estabilidad.

Pasos prácticos:

1. Elige un directorio problemático y ejecuta: namei -l, stat, getfacl y una prueba de creación como usuario real.
2. Haz backup de ACLs del subtree antes de cambiar algo significativo.
3. Activa setgid y ACLs por defecto en directorios de colaboración; corrige máscaras para que “concedido” signifique “efectivo”.
4. Acota cambios de propiedad/grupo con predicados de find; prefiere chgrp sobre chown cuando puedas.
5. Después del incidente, documenta la política prevista y añade un job de auditoría para detectar drift antes de la próxima migración.

Los permisos no son difíciles porque Linux sea difícil. Son difíciles porque los humanos son inconsistentes, y el almacenamiento recuerda todo.