Búsqueda

martes, abril 26, 2005

Peligro inminente

El domingo pasado pusieron Peligro Inminente, la tercera pelícla basada en el personaje de Tom Clancy, Jack Ryan, aunque la segunda con Harrison Ford haciendo de Ryan. Me vino a la cabeza una escena que en su día me pareció "extraña", y que ahora, años después, puedo decir que no es real. Hay un momento en el que Ryan consulta a un colega informático para "entrar" en el ordenador de Ritter (creo que era Ritter). Le da una serie de instrucciones, una de las cuales es esperar a que Ritter encienda el ordenador y teclear algo (supongo que para "espiar" y obtener su contraseña). Pero luego le llama diciendo que ha olvidado comentarle que el paso final debe hacerlo cuando Ritter ya se haya ido, porque si no se dará cuenta. Efectivamente, el director nos muestra un plano de la pantalla de Ritter donde aparece un mensaje de texto que indica que hay un terminal conectado.

Bueno, vamos a pensar un poco. Si Ryan debía esperar a que Ritter se fuera, es que podía "entrar" con el ordenador de Ritter apagado. El sentido común nos dice entonces que no intentaba entrar en el ordenador de Ritter, como nos dicen en la película, sino a algún tipo de servidor central, utilizando las credenciales de Ritter y poder acceder a su información. Este es el clásico caso en el que los ordenadores personales no se usan más que como terminales para acceder a un ordenador central, donde realmente está la información, y donde realmente se ejecutan los programas. Pero en este caso, no tiene mucho sentido la alerta que aparece en el terminal de Ritter indicando que hay alguien más conectado. En un sistema centralizado, un usuario puede entrar desde cualquier terminal, y al servidor le da igual desde dónde se conecta uno, sólo qué credenciales (normalmente nombre y contraseña) se utilizan.

Uno puede suponer que después de todo, se trata de un sistema que utilizan altos funcionarios, así que debería incluir mecanismos de seguridad como ese. De hecho, un sistema centralizado puede configurarse para que determinados usuarios sólo puedan acceder desde determinados terminales, y cualquier usuario puede saber cuántos clientes tiene abiertos sin más que teclear un comando. Pero por el tratamiento que se le da (la alerta en el pie de la pantalla), más bien parece un caso de "malainformática".

Si lo anterior, aunque discutible, es al menos posible, lo que sigue es totalmente irreal: Ritter comienza a borrar archivos y en el terminal de Ryan, éstos desaparecen inmediatamente en mitad de su lectura. Vamos a ver, cuando uno intenta borrar un fichero y alguien lo tiene abierto, no desaparece de la vista del que lo tiene abierto. En estos casos, pueden ocurrir dos cosas: o bien el sistema deniega el intento de borrado y advierte al usuario de que el fichero está siendo utilizado, como ocurre en Windows, o bien el fichero se borra pero la aplicación que lo tiene abierto mantiene su copia de memoria, como ocurre en UNIX, y el usuario puede seguir accediendo a él (al menos, hasta que llegue a algún punto en el que la aplicación necesite "recargar" los datos desde el disco y descubra que ya no están). Pero lo que no ocurrirá nunca, jamás de los jamases, es que si un usuario tiene el fichero abierto y lo está leyendo, desaparezca todo el texto inmediatamente.

El final de la escena, más que un error es una ingenuidad. A medida que los ficheros desaparecen, Ryan consigue en última instancia imprimir el más importante (con la inevitable secuencia de tensión porque la impresora no está lista). Papel en mano, Ryan se encara con Ritter y esgrime el recién impreso documento como si fuera una prueba definitiva. Como he dicho, esto es una ingenuidad, ya que un documento impreso enteramente por una impresora, sin ningún tipo de sello o firma (y me refiero a sellos de estampar, no logotipos que puedan venir en el documento) no tiene validez alguna. Cualquiera puede hacer lo que quiera con un editor de texto y una impresora, y por eso carece de validez legal.

6 comentarios:

  1. Mañana imprimo un documento por el que Bill Gates cede todas sus acciones a Ikaru. ^_^

    ResponderEliminar
  2. Demasiado tarde. Me he adelantado, y ahora tengo un documento que dice que soy propietario de Microsoft, de Sun y de IBM.

    ¡Bwah ha ha ha ha!

    ResponderEliminar
  3. Me acuerdo perfectamente de esa escena. Y es digno de admirarse que una escena ingenua como esa cause esa tensión en el espectador, esto es porque cuando uno va a ver una pelicula tiene uno que volverse credulo de lo contrario la pelicula no se disfruta y si no se disfruta no vale la pena lo que se pago por ir a verla.

    ResponderEliminar
  4. Creo que en la película GHOST aparece algo similiar con el asunto de los ficheros borrados y los mensajes en la pantallita.

    De todas maneras podría tratarse no de un servidor centralizado sino quizá es que Ritter tenía una carpeta compartida con contraseña, y el buneo de Ford desde otro PC quiso crearse una unidad con dicha carpeta (por lo que pediría su login/password). :-S

    ResponderEliminar
  5. Una pequeña puntualización (si, ¡sobre un post de 2005!):

    En UNIX cuando un proceso tiene abierto un fichero y este se borra con un comando lo que ocurre no es que el fichero siga en memoria. La explicación que voy a dar no es necesariamente exacta, pero sí más aproximada.

    El proceso abierto tiene un "handle" que no apunta hacia el nombre y ruta del fichero, sino hacia el i-nodo (la estructura que describe el contenido del fichero en el disco). Cuando borramos un fichero con rm, borramos la relación de la ruta/nombre con el i-nodo, pero como el i-nodo sigue en uso, el archivo físico no se borra.

    Un uso explícito de este efecto son los "hard links": varias rutas/nombres apuntan al mismo fichero físico.

    Se observa muy bien en la rotación de las bitácoras (logs, los registros de operaciones de un servidor). El mecanismo suele ser el siguiente:

    - Se renombra el fichero de log sobre el que está escribiendo el fichero. Por ejemplo de httpd.log a httpd.log.2009-02-16
    - Dado que la aplicación que tiene el fichero abierto (el servidor) apunta al fichero físico, éste sigue escribiendo en el mismo, pero ahora el nombre que apunta a ese fichero es otro. El efecto es que parece que el servidor se hubiera enterado del cambio de nombre y ahora escribiera en el nuevo (httpd.log.2009-02-16), pero no es así. Escribe en el mismo fichero, aunque éste sea visible con un nuevo nombre.
    - En el momento exacto de la rotación (habitualmente con el cambio de día), el servidor recibe una notificación, cierra el antiguo fichero y abre uno con el mismo nombre. Como el nombre que indica (httpd.log en nuestro ejemplo) ya no apunta a ningún fichero, el proceso crea un nuevo fichero sobre el que seguirá escribiendo la bitácora.

    ResponderEliminar
  6. Gracias por el apunte.

    Precisamente, hace poco he tenido algún percance con ficheros de log que se comportaban "misteriosamente", por ese motivo.

    ResponderEliminar