Probar y versionar políticas de acceso

Una política de acceso se prueba con casos: «este usuario, esta acción, este recurso, se espera permitir o denegar». Cada vez que la política cambia, se corren todos los casos y se compara lo obtenido con lo esperado. Un caso que antes pasaba y ahora falla es una regresión: el cambio rompió algo que funcionaba.

El valor está en los casos de denegar, porque el error típico de una política no es negar de más (alguien se queja de inmediato) sino permitir de más (nadie lo nota hasta que alguien abusa). Una buena suite tiene tantos casos de «debe negar» como de «debe permitir».

Abre el laboratorio. En la carpeta quebrabrava hay tres archivos: historial.txt con las cuatro versiones, casos.txt con los diez casos de prueba y su resultado en cada versión, y repeticion_t07.txt con una repetición hecha hoy. Úsalos con ls y cat.

La norma interna del instituto es que todo cambio lleve un revisor distinto del autor. Busca la versión que se publicó sin esa revisión.

En casos.txt cada fila compara lo esperado con lo obtenido en cada versión. Una prueba que avisa de un problema es una prueba que funciona: el trabajo del equipo es leerla. Con la versión que publicó el cambio sin revisión, un caso dejó de dar lo esperado. Era un caso de denegar, y la política permitió.

Hay una forma de volver verde una suite sin arreglar nada: borrar el caso que falla. En la última columna de casos.txt un caso aparece como retirado. Cruza ese dato con repeticion_t07.txt, donde se corrió hoy ese caso contra la última versión, y mira si la política da lo que ese caso esperaba.

La fecha de publicación de cada versión está en historial.txt. Una versión con un fallo conocido estuvo vigente desde el día de su publicación hasta el día en que se publicó la siguiente. Calcula cuántos días corrieron entre las dos fechas: ese es el tiempo en que la política permitió lo que debía negar.