Por qué una solución técnicamente correcta puede fallar en producción: permisos en Linux, casos no contemplados y la importancia del criterio humano.
La inteligencia artificial se ha convertido en una herramienta habitual para quienes trabajamos en administración de sistemas, infraestructura y desarrollo de software.
Hoy podemos compartir un mensaje de error, una configuración o la salida de un comando y recibir, en segundos, un diagnóstico y una posible solución.
Y lo interesante es que, cada vez con mayor frecuencia, las respuestas son técnicamente correctas.
Los modelos actuales conocen buenas prácticas de seguridad, principios de diseño y procedimientos de diagnóstico. Pueden interpretar logs, identificar problemas de configuración y proponer alternativas razonables.
Pero esto introduce un riesgo que considero particularmente interesante: una solución puede ser técnicamente correcta y, aun así, no ser adecuada para todas las condiciones en las que funciona un sistema.
El problema no siempre está en lo que la IA responde. A veces está en lo que no sabe, en lo que no preguntamos o en los supuestos que aceptamos sin verificar.
Cuando chmod 777 resolvía todos los problemas
Durante años, uno de los ejemplos clásicos de malas prácticas en Linux ha sido utilizar chmod 777 para resolver errores de permisos.
Una aplicación no puede escribir en un directorio y devuelve:
Permission deniedUna solución rápida consiste en ejecutar:
sudo chmod -R 777 /var/www/myapp/uploadsEl error desaparece y la aplicación comienza a funcionar.
Pero el comando concede permisos de lectura, escritura y ejecución al propietario, al grupo y a todos los demás usuarios. Aplicado recursivamente, también puede otorgar permisos innecesarios sobre archivos y directorios.
El problema funcional puede desaparecer a costa de introducir un problema de seguridad.
Una solución más apropiada requiere identificar qué usuario ejecuta el proceso, qué permisos necesita y qué otros procesos deben acceder a esos archivos.
Por ejemplo, si el directorio debe ser administrado exclusivamente por un usuario de servicio llamado myapp, podríamos asignarle la propiedad:
sudo chown -R myapp:myapp /var/www/myapp/uploadsY configurar permisos diferenciados:
sudo find /var/www/myapp/uploads -type d -exec chmod 750 {} \;
sudo find /var/www/myapp/uploads -type f -exec chmod 640 {} \;Naturalmente, estos permisos deben ajustarse si otros procesos necesitan acceder a los archivos.
Este ejemplo fue útil durante mucho tiempo para ilustrar el riesgo de aceptar recomendaciones sin comprender sus consecuencias.
Sin embargo, los asistentes de IA actuales suelen reconocer perfectamente estos problemas. Ante un error de permisos, muchos recomiendan revisar propietarios, grupos, usuarios de ejecución y aplicar el principio de mínimo privilegio.
La cuestión ya no es solamente si la IA conoce las buenas prácticas. Es si dispone de suficiente información para aplicarlas correctamente a nuestro sistema.
Y aquí aparece un problema menos evidente.
Una solución correcta que deja de funcionar
Consideremos un caso de administración de sistemas.
Un servidor Ubuntu ejecuta periódicamente un script que actualiza un registro DNS en Amazon Route 53 cuando cambia su dirección IP pública.
El script está configurado en el crontab del usuario ubuntu:
*/5 * * * * /usr/local/bin/update-route53-ddns.sh >> /var/log/route53-ddns.log 2>&1La tarea debe ejecutarse cada cinco minutos y registrar su salida en un archivo ubicado en /var/log.
Sin embargo, las actualizaciones no se están realizando.
Al consultar los registros del sistema:
sudo grep 'update-route53-ddns' /var/log/syslogEncontramos entradas como esta:
CRON[707684]: (ubuntu) CMD (/usr/local/bin/update-route53-ddns.sh >> /var/log/route53-ddns.log 2>&1)Cron está intentando ejecutar la tarea.
Pero eso no significa que el script haya comenzado a ejecutarse.
Para reproducir el problema podemos utilizar:
sudo -u ubuntu /bin/sh -c '/usr/local/bin/update-route53-ddns.sh >> /var/log/route53-ddns.log 2>&1'El resultado es:
/bin/sh: 1: cannot create /var/log/route53-ddns.log: Permission deniedLa causa queda identificada.
La redirección >> es procesada por el shell antes de ejecutar el script. Como el usuario ubuntu no puede abrir el archivo de log para escritura, el script ni siquiera comienza a ejecutarse.
Un asistente de IA puede recomendar:
sudo touch /var/log/route53-ddns.log
sudo chown ubuntu:ubuntu /var/log/route53-ddns.log
sudo chmod 644 /var/log/route53-ddns.logLa recomendación es razonable y respeta el principio de mínimo privilegio para el archivo en cuestión.
El usuario ubuntu puede escribir en el log sin necesidad de modificar los permisos del directorio /var/log.
Ejecutamos nuevamente el script:
/usr/local/bin/update-route53-ddns.sh >> /var/log/route53-ddns.log 2>&1
echo $?Y obtenemos:
0El script termina correctamente, según su código de salida.
La IA identificó el problema, explicó su causa y propuso una solución correcta.
Hasta aquí, todo funciona.
El problema que aparece semanas después
La tarea cron comienza a ejecutarse correctamente cada cinco minutos. El usuario ubuntu puede escribir en /var/log/route53-ddns.log, el script se ejecuta y las actualizaciones de DNS funcionan como se esperaba.
El problema parece resuelto.
Sin embargo, hay un detalle que no fue considerado: cada ejecución agrega información al archivo de log mediante la redirección >>.
La tarea se ejecuta 288 veces por día, más de 8.600 veces por mes.
Si el script produce suficiente información y no existe una política de rotación o retención, el archivo continuará creciendo indefinidamente.
Durante los primeros días, esto probablemente no represente un problema. Pero semanas o meses después, especialmente en un servidor con poco espacio disponible, el filesystem que contiene /var/log podría quedarse sin espacio.
Podemos comprobar el espacio disponible y el tamaño del log mediante:
df -h /var/log
du -h /var/log/route53-ddns.logCuando el espacio disponible se agota, pueden comenzar a aparecer errores como:
No space left on deviceLas consecuencias podrían extenderse mucho más allá del script original. Otros servicios pueden dejar de escribir sus logs, algunas aplicaciones pueden fallar al crear archivos temporales y, dependiendo de la distribución del almacenamiento, incluso pueden verse afectados componentes críticos del sistema.
La solución original no era incorrecta. Resolvía el problema de permisos que habíamos identificado, pero no contemplaba una consecuencia de mantener esa solución funcionando a lo largo del tiempo.
Un asistente de IA podría haber sugerido configurar logrotate, limitar el tamaño del archivo o modificar el script para registrar solamente los cambios de IP y los errores.
También podría habernos propuesto conservar únicamente la salida de la última ejecución utilizando > en lugar de >>, si no necesitábamos mantener un historial.
Todas son alternativas razonables, pero dependen de cómo queremos administrar los registros y qué información necesitamos conservar.
El asistente resolvió correctamente el problema que le presentamos. Sin embargo, no necesariamente conocía los requisitos de observabilidad, la capacidad de almacenamiento disponible ni las políticas de mantenimiento del servidor.
El riesgo no estaba en el comando recomendado, sino en asumir que una solución que funciona correctamente hoy seguirá siendo adecuada indefinidamente.
Los casos no contemplados: cuando cambian las condiciones
En ingeniería de software utilizamos el término corner case para describir situaciones particulares que aparecen bajo determinadas combinaciones de condiciones y que pueden no estar contempladas en el funcionamiento habitual.
No siempre son escenarios extremadamente improbables. Algunos ocurren regularmente, pero pasan inadvertidos durante las pruebas iniciales.
Consideremos otro ejemplo.
Una tarea cron ejecuta un script de mantenimiento cada cinco minutos:
*/5 * * * * /usr/local/bin/maintenance.shEl script funciona correctamente cuando se ejecuta manualmente.
También funciona durante las primeras ejecuciones programadas.
Pero ¿qué sucede si, por alguna razón, una ejecución tarda diez minutos?
Cron no espera automáticamente a que termine la ejecución anterior.
Por lo tanto, podría iniciar una segunda instancia mientras la primera continúa trabajando.
Si ambas modifican los mismos archivos, procesan los mismos registros o actualizan un recurso compartido, pueden producirse condiciones de carrera e inconsistencias.
El problema no aparece necesariamente durante una prueba manual.
Tampoco se manifiesta si el script normalmente tarda pocos segundos.
Solamente aparece cuando su duración supera el intervalo de ejecución y existe un conflicto entre las instancias concurrentes.
Una alternativa consiste en utilizar flock para impedir ejecuciones simultáneas:
*/5 * * * * /usr/bin/flock -n /tmp/maintenance.lock /usr/local/bin/maintenance.shEn este caso, si una instancia mantiene el bloqueo, las siguientes ejecuciones no iniciarán el script hasta que el recurso esté disponible. Con la opción -n, las ejecuciones que no puedan obtener el bloqueo terminarán inmediatamente, sin esperar.
Esto también tiene una consecuencia: algunas ejecuciones programadas pueden omitirse. Dependiendo de la aplicación, ese comportamiento puede ser aceptable o no.
Nuevamente, no existe una solución universal.
El conocimiento técnico permite identificar las condiciones bajo las cuales una recomendación deja de ser suficiente.
El riesgo de confiar en respuestas que suelen ser correctas
Uno de los aspectos más interesantes de la evolución de los asistentes de IA es que sus recomendaciones se han vuelto progresivamente más útiles y sofisticadas.
Esto puede modificar nuestra forma de utilizarlos.
Cuando una herramienta produce respuestas equivocadas con frecuencia, tendemos a desconfiar y revisar sus resultados.
Pero cuando sus recomendaciones funcionan repetidamente, es natural comenzar a aceptarlas con menos verificaciones.
El riesgo no depende solamente de la probabilidad de que el modelo se equivoque.
También depende de nuestra disposición a detectar una recomendación incompleta o inapropiada antes de aplicarla.
En administración de sistemas, una respuesta aparentemente correcta puede involucrar supuestos que no fueron explicitados:
- Que un archivo conservará sus permisos y propietario.
- Que un script nunca se ejecutará simultáneamente con otra instancia.
- Que las credenciales disponibles durante una prueba manual también estarán presentes en cron.
- Que modificar una configuración no afectará a otros servicios.
- Que una operación puede repetirse sin provocar efectos secundarios.
- Que una solución válida para un servidor también funcionará en todos los demás.
Algunas de estas condiciones pueden verificarse fácilmente.
Otras requieren conocer la arquitectura, las dependencias, los procedimientos operativos o incluso decisiones históricas que no están documentadas.
Un modelo puede ayudarnos a identificar estos riesgos, pero necesita disponer de información suficiente o formular las preguntas apropiadas.
Y nosotros debemos reconocer cuándo esa información falta.
De pedir soluciones a validar hipótesis
Una de las formas de aprovechar mejor los asistentes de IA consiste en utilizarlos como herramientas de diagnóstico y no solamente como generadores de comandos.
En lugar de solicitar directamente una solución, podemos pedir que identifiquen hipótesis, propongan verificaciones y expliquen bajo qué condiciones sería válida cada alternativa.
Por ejemplo, ante el problema de cron, podríamos formular una consulta como esta:
Tengo un script ejecutado mediante cron como usuario ubuntu. La tarea aparece en syslog, pero no produce el resultado esperado. Su salida se redirige a un archivo ubicado en /var/log.
Quiero identificar la causa antes de modificar permisos.
Proponé pruebas para distinguir entre un error de redirección, un problema de ejecución del script y un problema con el entorno de cron.
Una vez identificada la causa, proponé la modificación mínima necesaria e indicá qué condiciones podrían hacer que la solución falle posteriormente.
La diferencia es importante.
No estamos pidiendo solamente un comando que haga desaparecer el error.
Estamos solicitando un procedimiento que permita comprender y verificar el comportamiento del sistema.
También podemos pedirle al asistente que revise su propia recomendación:
¿Qué supuestos estás haciendo? ¿En qué condiciones podría fallar esta solución? ¿Qué efectos secundarios debería verificar antes de aplicarla en producción?
Estas preguntas no garantizan que el modelo identifique todos los problemas posibles.
Pero pueden mejorar considerablemente la calidad del análisis y ayudar a descubrir condiciones que inicialmente no habíamos considerado.
El criterio técnico sigue siendo necesario
La inteligencia artificial está transformando el trabajo de quienes administramos infraestructura y desarrollamos software.
Muchas tareas que antes requerían consultar documentación, investigar errores y comparar configuraciones pueden resolverse hoy con mayor rapidez.
Eso representa una ventaja considerable.
Pero también cambia el valor de determinadas habilidades profesionales.
Recordar la sintaxis exacta de un comando resulta cada vez menos importante que comprender qué hace, sobre qué recursos actúa y cuáles pueden ser sus consecuencias.
Lo mismo ocurre con las configuraciones de servicios, las políticas de seguridad o los cambios de infraestructura.
Saber ejecutar un comando no equivale a comprender el sistema en el que se ejecuta.
Y obtener una respuesta correcta no equivale a haber validado una solución.
En entornos productivos, una modificación debe evaluarse considerando no solamente el problema inmediato, sino también sus efectos sobre otros componentes, su comportamiento ante fallos y las condiciones en las que continuará funcionando.
Esto es especialmente relevante en infraestructura, donde una decisión aparentemente pequeña puede afectar permisos, disponibilidad, seguridad o integridad de los datos.
Los asistentes de IA pueden ayudarnos a analizar estas situaciones.
Pero la responsabilidad de comprender el contexto, evaluar los riesgos y decidir qué cambios aplicar continúa siendo nuestra.
Conclusión
Durante mucho tiempo, chmod 777 fue un ejemplo sencillo de cómo una solución podía eliminar un error y, al mismo tiempo, introducir un problema de seguridad.
Los asistentes de IA actuales suelen reconocer esta mala práctica y proponer alternativas mucho más adecuadas.
Sin embargo, el desafío ha evolucionado.
Hoy debemos prestar atención no solamente a las respuestas incorrectas, sino también a las respuestas correctas que pueden resultar incompletas.
Un script puede funcionar correctamente hasta que su log consume todo el espacio disponible. Otro puede ejecutarse sin errores hasta que dos instancias coinciden y modifican simultáneamente los mismos recursos. Una configuración puede resolver un problema local, pero afectar a otro componente del sistema.
Son ejemplos de situaciones en las que una solución aparentemente válida necesita ser revisada dentro de un contexto más amplio.
Cuanto más confiables se vuelven los asistentes de IA, más importante resulta conservar nuestra capacidad de cuestionar sus supuestos y validar sus recomendaciones.
No se trata de desconfiar sistemáticamente de la inteligencia artificial, sino de integrarla en una metodología de trabajo basada en el diagnóstico, la comprensión y la verificación.
La IA puede acelerar considerablemente la resolución de problemas y ayudarnos a identificar alternativas que no habíamos considerado.
Pero una respuesta correcta no garantiza una solución completa.
La IA puede decirnos cómo resolver un problema. Nuestro conocimiento técnico debe permitirnos determinar si esa solución seguirá siendo correcta cuando cambien las condiciones del sistema.
