3 Power Tips + Power Link I13

Leer un comando antes de correrlo y autorizarlo por su nombre son decisiones que se toman sobre un texto. Lo que el proceso puede hacer una vez que arrancó se decide en otro lado.

Power Tip #1 El comando que leés no es el que corre

El script del pipeline está versionado y lo revisaste entero. Dice $CLEAN "$d" y en el repositorio no aparece dónde se define CLEAN.

• No aparece porque no vive ahí: lo inyecta la plataforma de CI, desde la configuración del job o desde un grupo de variables que se edita en otra pantalla.
• Una función viaja igual de callada. export -f ls la manda al ambiente, y en el hijo esa función le gana al binario del mismo nombre.
• El alias, en cambio, no viaja: en un script no se expande salvo que lo habilites. Es el único de los tres que se queda donde lo ves.

env | grep -E '^CLEAN=|BASH_FUNC'   # como paso del job: lo que el script usa y no declara

Leer el repositorio asume que el repositorio es el programa. La otra mitad la pone el ambiente donde corre el job y no está versionada, así que queda fuera del alcance de cualquier revisión del código. El nombre y lo que ejecuta son dos cosas distintas hasta que los resolvés en el proceso donde va a correr.

Power Tip #2 Permitir un comando es permitir todo lo que ese programa es capaz de hacer

La regla de sudoers autoriza less /var/log/secure y nada más. Leer un log con un visor: se abre, se lee, se cierra. Parece prudente y acotado.

• less no solo muestra. Con ! corre un comando en una shell —la que diga $SHELL—, con | manda el contenido a otro programa y con v abre el editor. No es un agujero: está en su manual, en la lista de comandos.
• Tampoco es una particularidad de less. vim sale a la shell con :!, find ejecuta programas con -exec, tar canaliza lo que extrae a un programa externo con --to-command. Ninguno está roto: todos hacen lo que su documentación dice.
• "Solo lectura" describe para qué lo autorizaste, no lo que el programa puede hacer una vez abierto. La regla nombra un archivo y entrega todo lo que ese archivo es capaz de hacer, incluido lo que le delegue a otro.

sudo -l   # de cada línea: ¿qué más puede hacer ese programa, y a quién llama?

Enumerar lo que se puede correr te ahorra tener que prever cada cosa que no querés que corra, y eso no es poco. Lo que no te da es un límite a lo que esos comandos pueden hacer: el nombre autorizado no dice hasta dónde llega el proceso una vez que arrancó, y averiguarlo binario por binario no escala. Ese límite hay que ponerlo en otro lado.

Power Tip #3 sudo dice quién; systemd dice hasta dónde

El job de mantenimiento corre autorizado por una regla de sudoers que nombra un solo script. Mientras corre, tiene el filesystem entero a mano, /home incluido.

• La regla contestó una pregunta —quién puede correr qué— y no hay nada en ella que conteste la otra. El alcance del proceso no se decide en sudoers porque sudoers no habla de eso.
• La otra pregunta se responde en la unidad. ProtectHome=, ProtectSystem=, PrivateTmp= le recortan al proceso lo que puede tocar, sin tocar la autorización ni el script. No compiten con sudo: arrancan donde sudo termina.
• Ahora, no le creas al archivo. En scope de usuario, según la versión de systemd, esas propiedades pueden necesitar además PrivateUsers=yes para hacer efecto — sin error, y con systemctl show confirmándote que están puestas.

systemd-run --user --pty --property=ProtectHome=yes ls -a $HOME   # si te lista el home, acá no rige

Las dos preguntas se responden en lugares distintos y ninguna cubre la de la otra. Antes de apoyarte en la segunda, hacela fallar a propósito: pedile al proceso lo que no tendría que poder, y fijate si puede.

Power Link

La discusión sobre IA y software libre suele quedarse en si el código generado sirve o no. Debian se está haciendo una pregunta más de fondo: quién puede contribuir y con qué. La resolución general en debate hasta el 8 de agosto junta seis propuestas en la misma votación, desde prohibir las contribuciones asistidas por LLM en el Contrato Social hasta no pronunciarse y dejarlo al criterio de cada quien: General Resolution: LLM usage in Debian. Cuando esto se publica todavía no se votó, que es el mejor momento para leerlas: las seis están argumentadas y firmadas, cosa poco frecuente en una discusión sobre este tema.