Estos días se ha armado bastante revuelo en torno a una peculiar característica de Fedora 12: los usuarios normales pueden instalar aplicaciones sin necesidad de introducir la contraseña de root, siempre y cuando los paquetes estén firmados y provengan de un repositorio confiable.

Hasta esta versión, Fedora siempre preguntaba a los usuarios la contraseña de root para realizar tareas que requerían permisos administrativos. La decisión podía recordarse o no para posteriores ocasiones. Debido a esto, un usuario nuevo en el sistema nacía sin permisos y cada vez que necesitaba hacer alguna tarea administrativa nueva el administrador debía concedérselos, de forma temporal o permanente.

En Fedora 12 se quiso hacer algo mejor: se definieron unos roles básicos de usuario y se ideó una herramienta gráfica de gestión de roles. El problema es que ni los roles se definieron con suficiente perspectiva, ni la herramienta gráfica de gestión de roles se terminó a tiempo, ni se informó adecuadamente del cambio en las notas de la versión. ¿El resultado? Caos, decepción, críticas destructivas. Afortunadamente, ya existe una actualización que arregla este problema.

Un poco de historia

Tradicionalmente, en GNU/Linux y otros sistemas parecidos se ha utilizado la abstracción de los permisos sobre ficheros para definir las políticas del sistema. Por ejemplo, si un usuario está dentro del grupo audio tiene acceso al fichero /dev/dsp y por lo tanto quiere decir que puede utilizar la tarjeta de sonido.

Sobre este sistema básico se pueden introducir diferentes mecanismos, como sudo. Sudo permite configurar políticas para que usuarios normales puedan ejecutar aplicaciones como si fueran root, el superusuario, requiriendo o no autenticación. Estamos hablando de que puedan ejecutar programas completos como si fueran root, por lo que hay que ser muy conservador al utilizar este mecanismo para no comprometer el sistema.

Sudo se comenzó a utilizar ampliamente en las primeras versiones de Ubuntu para permitir realizar cualquier tarea de administración a los usuarios del grupo admin, siempre y cuando se autenticaran previamente introduciendo su propia contraseña.

…y entonces llegó PolicyKit

PolicyKit establece mecanismos más complejos de forma que aplicaciones ejecutadas por usuarios normales puedan comunicar acciones a aplicaciones privilegiadas. Estas aplicaciones privilegiadas son las que definen estos mecanismos, incluyendo los permisos por defecto y la explicación que se le da al usuario en caso de que requiera alguna acción por su parte —como introducir su contraseña. Este sistema se utiliza en casi todas las distribuciones modernas para gestionar tareas administrativas.

Por ejemplo, el notificador de actualizaciones de Ubuntu sabe que existen actualizaciones, pero no puede instalarlas por sí mismo porque no tiene permisos para ello, así que cuando el usuario pulsa en el botón «Aplicar actualizaciones» en realidad le manda un mensaje a otra aplicación que sí los tiene. Esta aplicación le dice: «Vale, amigo, pero necesito que el usuario se identifique. Cuando te pregunte por qué, explícale esto y esto otro». De esta forma, el usuario nunca llega a ejecutar una aplicación con una identidad que no le corresponde y todo el proceso es más seguro.

Entonces… ¿PolicyKit es algo bueno o malo?

No me cabe la menor duda de que PolicyKit es algo bueno. El problema llega cuando desde Fedora deciden ir un paso más allá creando un sistema de roles asignando diferentes privilegios por defecto a cada rol y en el proceso no participa ni el Tato: se toman las decisiones sin suficiente perspectiva y se provocan meteduras de pata como esta.

Afortunadamente, en el mundo del software libre las meteduras de pata se critican, se reconsideran… y en cuestión de días todo vuelve a la normalidad. Estoy seguro de que el próximo intento sí recibirá la atención que se merece y dentro de unos meses veremos una Fedora 13 muy avanzada en este aspecto.