El registro crece al añadir, pero no se puede recrear: revisa la ACL del directorio
Añadir a un archivo no necesita un nombre nuevo en su directorio; crearlo sí. Compara la ACL de acceso con los valores heredados antes de ampliar nada.
Un registro que no deja de crecer deja de crecer en el momento en que algo lo vuelve a crear, y el error dice permiso denegado. La conclusión tentadora es que el propio archivo necesita más permisos, aunque puede que la misma cuenta ya pueda escribirlo. Añadir a un nombre existente y crear uno nuevo son comprobaciones distintas, y solo la segunda consulta al directorio.
Añadir y crear son comprobaciones distintas
Abrir un archivo existente para añadir requiere permiso de escritura sobre ese archivo y permiso de búsqueda en cada directorio de su ruta. Crear un archivo requiere escritura y búsqueda en el directorio que lo contiene, porque la operación añade un nombre a ese directorio. Sustituir un archivo mediante un renombrado toca ambos directorios y sus reglas de sticky bit.
| Operation | What must permit it | Typical failure message |
|---|---|---|
| Append to an existing log | File write access, path traversal | Permission denied on the file |
| Create a missing log | Directory write and search access | Permission denied on the path |
| Rename a replacement into place | Both directories, plus sticky restrictions | Permission denied or operation not permitted |
Un descriptor ya abierto añade un cuarto caso. Un proceso puede mantener un identificador escribible abierto antes de perder privilegios y aun así fallar al reabrir la misma ruta con su identidad posterior. Los añadidos correctos y la creación fallida pueden ser ciertos a la vez, para el mismo proceso.
Las ACL predeterminadas se heredan, no conceden
Una entrada que empieza por el prefijo predeterminado describe lo que los objetos nuevos heredan del directorio. No concede nada al directorio en sí y no repara la ACL de un archivo que ya existe.
namei -l /var/log/openvpn/server.log
getfacl -p /var/log/openvpn
getfacl -p /var/log/openvpn/server.logLee las entradas de acceso por separado de las predeterminadas y lee la máscara. Una entrada con nombre que muestra derechos plenos puede seguir limitada por la máscara, por eso el comentario de eficacia importa más que las letras de la primera línea.
Usa la ruta resuelta en lugar de la ruta de la configuración. Un enlace simbólico, un punto de montaje o un directorio rotado pueden colocar el archivo real donde el permiso que concediste nunca llega. Recorre la ruta primero con namei y luego compara cada nivel con la cuenta en cuestión. Adivinar el directorio de nivel superior es cómo una corrección aterriza un nivel demasiado arriba.
Identifica quién escribe en ese momento
Revisa la unidad de servicio, sus drop-ins y la configuración de cuenta del propio demonio antes de cambiar nada. El proceso que añade y el que recrea pueden ser distintos: un ayudante de rotación, un escritor de estado y un lector web rara vez comparten identidad.
Una ejecución de prueba desde un shell de root no reproduce un servicio restringido, y tendrá éxito mientras el servicio sigue fallando. Reproduce la operación que falla en la misma unidad, con la misma cuenta y los mismos ajustes de sandbox. Si no puedes, arranca la unidad con un shell temporal y comprueba la identidad que informa. Cualquier otra cosa mide tu terminal en lugar del servicio.
Si de verdad hace falta crear, concede al escritor acceso al directorio de registro dedicado y mantén separado el acceso de lectura para los consumidores. Hacer escribible una cuenta compartida o todo un árbol de aplicación para satisfacer una sola llamada de registro cambia un problema pequeño por uno grande.
Rota sin reintroducir el fallo
Quien recrea el archivo decide su propietario y su modo para el siguiente ciclo, así que coordina la corrección con la configuración de rotación. Un reemplazo creado con otra cuenta o con una ACL nueva devuelve el fallo después de una corrección exitosa.
Fija el modo y el grupo al crear, no después, y verifica la siguiente rotación en lugar del siguiente añadido. Un añadido solo repite la prueba que ya pasó. Si la herramienta de rotación ofrece un ajuste de modo de creación, úsalo en vez de un chmod posterior. El hueco entre la creación y el chmod es justo cuando puede fallar la siguiente escritura.
Cuando el truncado falla de todos modos, deja de añadir permisos
Un fallo al truncar un archivo en el que puedes escribir no se explica por los permisos del directorio, y añadir más de ellos no ayudará. Mira mejor los atributos y el confinamiento: un atributo de solo añadir permite escrituras solo en modo de añadido, y un montaje de solo lectura o un sandbox de servicio pueden denegar una operación que la ACL permite.
Revisa las restricciones de sistema de archivos de la unidad y las opciones de montaje de la ruta, y después reproduce la operación exacta que falló. Ampliar un permiso que nunca se consultó solo oculta qué restricción era la real. Quita una restricción cada vez en una unidad desechable y reviértela antes de cambiar algo permanente.