1.5: Permisos y Ejecutables

Como se mencionó anteriormente, la raíz del administrador configura la mayoría de las cosas en el sistema, como dónde se montan las unidades de red y cómo se otorga el acceso al sistema. ^[1] La mayoría de los archivos que son importantes para estas configuraciones son “propiedad” de root, y por razones de seguridad, otros usuarios no pueden manipularlos. De hecho, todos los usuarios del sistema suelen ser dueños de los archivos en su propio directorio home, y estos archivos no pueden ser manipulados por otros usuarios (excepto el root, que tiene acceso a todo). Estas configuraciones de seguridad se controlan a través de permisos asociados a cada archivo y directorio.

Root también puede unir a los usuarios en grupos, permitiendo a los usuarios del mismo grupo compartir archivos entre sí pero no con extraños, si así lo desean. Los grupos pueden tener más de un usuario, y un solo usuario puede formar parte de más de un grupo, como en el siguiente ejemplo que ilustra tres grupos y ocho usuarios.

El comando groups muestra los grupos a los que pertenece un usuario; en el ejemplo anterior, groups oneilst reportaría emrichlab y hellmannlab. Para ver tus propios grupos, siempre puedes usar algo así como grupos $USER (confiando en el shell para reemplazar $USER con tu nombre de usuario).

Desafortunadamente, no hay una manera segura o fácil de enumerar a todos los miembros de un grupo en particular, al menos no sin un conocimiento profundo de cómo está configurado el sistema o alguna experiencia en programación. En algunos sistemas, un comando como getent group <groupname>proporcionará la respuesta; los profesores del grupo getent reportarían emrichs, schmidtj y hellmannj para el ejemplo anterior.

Si no estás seguro del nombre de usuario de una persona, el comando finger puede venir al rescate. Puede proporcionar un dedo con un nombre o apellido para buscar (o incluso el nombre de usuario, si se conoce), y devolverá información, si es ingresada por el administrador del sistema, sobre ese usuario.

Cada archivo y directorio está asociado con un usuario (el propietario) y un grupo; desafortunadamente, en los permisos normales similares a Unix, uno y solo un grupo pueden estar asociados a un archivo o directorio. Cada archivo y directorio también tiene asociados con él permisos que describen:

1. lo que puede hacer el propietario,
2. qué pueden hacer los miembros del grupo, y
3. lo que todos los demás (los demás) pueden hacer.

Esta información se muestra cuando se ejecuta ls -l, y se representa mediante una combinación de r (leer), w (escribir) y x (ejecutar). Donde uno de estos tres está ausente, se sustituye por a -. Aquí hay un ejemplo, que muestra dos entradas propiedad de oneils y en el grupo iplant-everyone; una tiene permisos rwxrwxrwx (un conjunto de permisos inseguro, que permite a cualquiera hacer cualquier cosa con el archivo), y la otra tiene rwxr-xr-x (un permiso mucho más razonable conjunto).

Hay una entrada extra en la primera columna; el primer carácter describe el tipo de entrada, - para un archivo regular y d para directorio. Vamos a desglosar estas primeras columnas para una de las entradas:

Cada archivo o directorio puede tener alguna combinación de permisos r, w y x, aplicados al usuario, al grupo u otros en el sistema. Para los archivos, los significados de estos permisos son bastante sencillos.

Código	Significado para Archivos
r	Puede leer el contenido del archivo
w	Puede escribir en (editar) el archivo
x	Puede (potencialmente) “ejecutar” el archivo

Cubriremos lo que significa que un archivo sea ejecutable en un poco. Para los directorios, estos permisos toman diferentes significados.

Código	Significado para Directorios
r	Puede ver el contenido del directorio (por ejemplo, ejecutar ls)
w	Puede modificar el contenido del directorio (crear o eliminar archivos/directorios)
x	Puede cd al directorio, y potencialmente acceder a subdirectorios

El directorio temp anterior le da al usuario todos los permisos (rwx), pero los miembros del grupo y otros solo pueden cd al directorio y ver los archivos allí (r-x); no pueden agregar o eliminar archivos o directorios. (Es posible que puedan editar archivos en temp, sin embargo, dependiendo de los permisos de esos archivos).

La utilidad chmod (modo de cambio) nos permite agregar o eliminar permisos. Hay dos tipos de sintaxis, la sintaxis de “carácter” más simple y la sintaxis numérica “octal”. Describiremos la sintaxis más simple y dejaremos la discusión de la sintaxis octal para aquellos lo suficientemente valientes como para leer la página del manual (man chmod).

Para aclarar, aquí hay algunos ejemplos de modificación de permisos para el archivo p450s.fasta.

Comando	Efecto
chmod go-w p450s.fasta	Eliminar escritura para grupo y otros
chmod ugo+r p450s.fasta	Agregar lectura para usuario, grupo y otros
chmod go-rwx p450s.fasta	Eliminar leer, escribir y ejecutar para grupos y otros
chmod ugo+x p450s.fasta	Agregar ejecutar para usuario, grupo y otros
chmod +x p450s.fasta	Igual que chmod ugo+x p450s.fasta

Si deseas modificar un directorio y todo lo que hay dentro, puedes agregar el indicador -R (R mayúscula esta vez para recursivo) a chmod. Para compartir un directorio de proyectos y todo lo que hay dentro para el acceso de lectura con los miembros del grupo, por ejemplo, puedes usar proyectos chmod -R g+r.

Hay algunas pequeñas cosas a tener en cuenta sobre los permisos de archivos y directorios. El primero es que si bien es posible cambiar el grupo de un archivo o directorio, solo puedes hacerlo con el comando chgrp si eres miembro de ese grupo.

Segundo, eres el dueño de los archivos que creas, pero generalmente solo el usuario root tiene acceso a la utilidad chown que cambia el propietario de un archivo existente (no sería muy agradable “regalar” a otro usuario un programa nefasto).

Tercero, si bien es conveniente poder abrir un directorio para que lo lean los miembros del grupo, hacerlo solo es útil si todos los directorios anteriores también son mínimamente accesibles. En particular, todos los directorios en la ruta a un directorio compartido necesitan tener al menos x para el grupo si van a ser accedidos de alguna manera por los miembros del grupo.

Ejecutables y $PATH

¿Qué es un “programa”? En un sistema similar a Unix, es un archivo que tiene permisos ejecutables para algún usuario o usuarios. (¡También ayuda si ese archivo contiene algunas instrucciones que tienen sentido para ejecutar!) A menudo, estos se codifican en un formato “binario”, simplemente cadenas largas de 0 y 1 que representan código de máquina que la CPU puede interpretar, pero en algunos contextos también pueden ser archivos de texto legibles por humanos. Muchos de los programas que hemos estado usando, como echo y ls, son archivos ejecutables que viven en el directorio /bin junto con muchos otros, incluyendo bash, nuestro programa shell.

Si nos gusta, incluso podemos intentar echar un vistazo a uno de estos con menos. Por ejemplo, podemos intentar examinar los contenidos del programa bash con menos /bin/bash; aunque menos reporta una advertencia de que el archivo está codificado en binario, no va a doler intentarlo.

Un archivo codificado en binario no se parece mucho cuando intentamos convertirlo a texto y verlo con menos. En cualquier caso, aquí hay una “regla de ejecución” que vamos a romper casi de inmediato: para que el shell ejecute un programa (archivo ejecutable), especificamos la ruta absoluta o relativa a él.

En este caso, nuestra regla de ejecución indicaría que para ejecutar el programa echo, especificaríamos la ruta absoluta /bin/echo hola, ya que el programa echo vive en /bin, o../../../../../../.. /bin/echo hola para la ruta relativa (porque /bin está cuatro carpetas por encima de nuestro directorio de trabajo actual).

Ahora para la parte que rompe reglas: ya sabemos que solo podemos ejecutar echo sin especificar una ruta al programa. Esto significa que cuando intentamos ejecutar un programa, el shell debe ser capaz de encontrar el archivo ejecutable de alguna manera. ¿Cómo se hace esto?

La respuesta, como ocurre con tantas preguntas que involucran el shell, es una variable de entorno llamada $PATH. Comprobemos el contenido de esta variable: ^[2]

La variable de entorno $PATH contiene una cadena simple, que describe una lista de rutas absolutas separadas por: caracteres. Cuando especificamos lo que le parece al shell como el nombre de un programa, busca en esta lista de rutas, en orden, un archivo ejecutable de ese nombre. Cuando escribimos echo, intenta /usr/local/sbin/echo, luego /usr/local/bin/echo, y así sucesivamente, hasta que lo encuentre en /bin/echo.

El primer archivo ejecutable coincidente que el shell encuentra en los directorios listados en $PATH es el que se ejecuta. Esto podría llevar a alguna travesura: si un compañero de trabajo con una inclinación por los chistes prácticos pudiera modificar tu variable $PATH, podría agregar su propio directorio home como primera entrada. A partir de ahí, podría crear un archivo ejecutable llamado, digamos, ls que hizo lo que quisiera, ¡y sin saberlo estarías ejecutando eso! Es posible que cualquier persona con acceso a tu cuenta modifique tu $PATH, por lo que es una buena idea no dejar abierta la ventana de tu terminal alrededor de nadie con un cobarde sentido del humor.

Si hay varios archivos ejecutables con el mismo nombre en esta lista de rutas, ¿podemos descubrir cuál ejecutará el shell? Sí: en bash podemos tomar esta determinación usando el comando which. ^[3]

¿Y un comando como cd? Podemos intentar usar cuál para localizar un programa llamado cd, pero encontraremos que no se reporta nada.

Esto se debe a que cd no es un programa (archivo ejecutable), sino más bien un “comando”, lo que significa que el shell nota que es una palabra clave especial que debe manejar, en lugar de buscar un archivo ejecutable con ese nombre. Dicho de otra manera, bash es realizar la acción, en lugar de llamar a un programa ejecutable externo. Conocer la diferencia entre los comandos manejados por el shell y los programas que son archivos ejecutables es un punto menor, pero uno que podría resultar confuso en casos como este.

Hacer archivos ejecutables

Hagamos algo decididamente raro, y luego volvamos y explicarlo. Primero, usaremos nano para crear un nuevo archivo llamado myprog.sh, usando el indicador -w para nano para asegurar que las líneas largas no se envuelven automáticamente (nano -w myprog.sh). En este archivo, haremos los dos primeros caracteres #! , seguida inmediatamente por la ruta absoluta al archivo ejecutable bash. En líneas posteriores, pondremos algunos comandos que podríamos ejecutar en bash, como dos llamadas de eco.

A pesar de que parece el #! (pronunciado “shebang”, rimando con “the bang”) la línea comienza en la segunda línea, en realidad es la primera línea del archivo. Esto es importante. Observe que nano se ha dado cuenta de que estamos escribiendo un archivo que es un poco extraño, y que ha activado alguna coloración. Es posible que su nano no esté configurado para este resaltado de sintaxis. Si no, no te preocupes: estamos creando un archivo de texto simple.

Después de guardar el archivo (Control-o, luego Enter confirmar el nombre del archivo a escribir) y salir nano (Control-X), podemos agregar permisos de ejecución al archivo (para todos, quizás) con chmod +x myprog.sh.

Parecería que podríamos haber creado un programa, tenemos un archivo ejecutable, y es posible que hayas adivinado que la sintaxis especial que hemos utilizado hace que el archivo sea ejecutable de manera significativa. Vamos a probarlo: de acuerdo con nuestra regla de ejecución, podemos especificar la ruta absoluta hacia ella para ejecutarlo.

¡Corrió! Lo que hemos creado se conoce como guión para ser dirigido por un intérprete; en este caso, el intérprete es bash. Un script es un archivo de texto con permisos de ejecución establecidos, que contiene comandos que pueden ser ejecutados por un intérprete, generalmente especificados a través de la ruta absoluta en la parte superior del script con un #! línea. Un intérprete es un programa que puede ejecutar comandos, a veces especificados en un archivo de script.

Lo que está sucediendo aquí es que el shell ha notado que el usuario está intentando ejecutar un archivo ejecutable, y pasa la ejecución al sistema operativo. El sistema operativo, a su vez, nota los dos primeros bytes del archivo (el #! caracteres), y en lugar de que la CPU ejecute el archivo como código binario de máquina, ejecuta el programa especificado en el #! línea, pasando a ese programa el contenido del archivo como “código” para ser ejecutado por ese programa. Porque en este caso el programa de interpretación es bash, podemos especificar cualquier comando que podamos enviar a nuestro shell, bash. Posteriormente, veremos que podemos crear scripts que utilizan intérpretes mucho más sofisticados, como python, para ejecutar código más sofisticado.

De acuerdo con nuestra regla de ejecución, también podemos ejecutar nuestro programa especificando una ruta relativa a él, como. /myprog.sh (que especifica ejecutar el archivo myprog.sh que se encuentra en el directorio de trabajo actual).

Esta es la forma más común de ejecutar archivos y programas que existen en el presente directorio de trabajo.

Si cambiamos a otro directorio de trabajo presente, como nuestro directorio home, entonces para ejecutar el programa de acuerdo con la regla de ejecución, tenemos que especificar nuevamente ya sea la ruta absoluta o relativa.

Este proceso es tedioso; nos gustaría poder especificar el nombre del programa, pero debido a que la ubicación de nuestro programa no está especificada en un directorio listado en $PATH, obtendremos un error.

Instalación de un programa

Para agregar nuestros propios programas al sistema para que podamos ejecutarlos a voluntad desde cualquier ubicación, necesitamos:

1. Obtener o escribir un programa ejecutable o script.
2. Colóquelo en un directorio.
3. Asegúrese de que la ruta absoluta a ese directorio se pueda encontrar en $PATH.

Tradicionalmente, la ubicación para almacenar los propios ejecutables personales se encuentra en el directorio home de uno, dentro de un directorio llamado local, dentro de un directorio llamado bin. Vamos a crear estos directorios (crearlos también era parte de un ejercicio anterior, por lo que puede que no sea necesario), y movemos nuestro archivo myprog.sh allí.

Esto logra los pasos 1 y 2. Para el paso 3, necesitamos asegurarnos de que nuestro directorio local/bin se pueda encontrar en $PATH. Debido a que $PATH es una variable de entorno, podemos establecerla con export, haciendo uso del hecho de que las variables de entorno dentro de comillas dobles (pero no comillas simples) se expanden a su contenido.

Debido a que el lado derecho del = se evalúa antes de que ocurra la asignación, la variable $PATH ahora contiene la ruta completa al directorio local/bin, seguida del contenido anterior de $PATH. ^[4] Si escribimos un nombre de programa sin especificar una ruta a él, ¡el shell buscará primero nuestra propia ubicación de instalación!

Solo hay un problema: cada vez que salimos y volvemos a iniciar sesión, se olvidan las modificaciones de las variables de entorno que hemos realizado. Afortunadamente, bash busca dos archivos importantes cuando se inicia: ^[5] (1) los comandos en el archivo.bash_login (en tu directorio home) se ejecutan cada vez que bash comienza como consecuencia de una sesión de inicio de sesión (por ejemplo, al ingresar una contraseña causa bash para iniciar), y (2) comandos en el archivo.bashrc (en su directorio home) se ejecutan cada vez que se inicia bash (por ejemplo, al iniciar sesión y cuando bash se ejecuta a través de un #! guión).

Si quieres ver un saludo amistoso cada vez que inicies sesión, por ejemplo, podrías agregar la línea echo “Hola $USER, ¡qué gusto volver a verte!” a su archivo.bash_login. Debido a que queremos que nuestro $PATH sea modificado incluso si bash de alguna manera comienza sin nuestro inicio de sesión, agregaremos el comando export al archivo.bashrc.

El archivo.bashrc puede tener información ya en él, lo que representa una configuración de shell predeterminada colocada allí cuando el administrador creó la cuenta. Si bien podemos agregar nuestros propios comandos a este archivo, debemos hacerlo al final, y debemos tener cuidado de no molestar a los otros comandos de configuración que probablemente estén ahí por una buena razón. Además, los comandos de este archivo deben estar libres de errores y tipos: ¡algunos errores son lo suficientemente malos como para evitar que inicies sesión! Usar el -w al editar el archivo con nano ayudará a asegurar que el editor no intente autoenvolver comandos largos que no deben romperse en varias líneas.

En la parte inferior de este archivo, agregaremos la línea de exportación:

Porque las líneas que comienzan con # son “comentarios” (no ejecutadas, aparte del #! line, por supuesto), podemos usar esta función para recordarnos a nuestro yo futuro cómo llegó esa línea en el archivo. Debido a que los comandos en estos archivos solo se ejecutan cuando se inicia el shell, para activar los cambios, basta con cerrar sesión y volver a iniciar sesión.

Ejercicios

1. Supongamos que un archivo tiene los siguientes permisos enumerados por ls -l: -rwxrw-r—. ¿Qué indica esta cadena de permisos sobre el archivo?
2. ¿Cuál es la diferencia entre export path="$HOME/local/bin: $PATH” y export PATH="$PATH: $INICIO/local/bin”? ¿En qué situaciones podría preferirse la primera sobre la segunda?
3. Agrega cuidadosamente la línea export path="$HOME/local/bin: $PATH” a tu .bashrc (suponiendo que tienes un directorio local/bin en tu directorio home, y tu shell predeterminado es bash). Asegúrese de no alterar ninguna línea ya presente, o de crear errores tipográficos que puedan impedirle iniciar sesión.
4. Crea un script ejecutable en tu directorio local/bin llamado myinfo.sh, que ejecuta echo en las variables de entorno $HOME, $PWD y $USER, y también ejecuta la utilidad date. Intenta ejecutarlo simplemente ejecutando myinfo.sh desde tu directorio home (es posible que tengas que cerrar sesión y volver primero, para que el shell reconozca el cambio en el contenido de las rutas listadas en $PATH si modificaste tu .bashrc).
5. Scripts bash ejecutables que comienzan con #! /bin/bash funcionará bien, siempre que el programa bash viva en el directorio /bin. En cualquier sistema donde este no sea el caso (probablemente una ocurrencia rara), no lo hará.

   Intenta crear un script bash donde la primera línea es #! /usr/bin/env bash. El programa env utiliza la variable $PATH para localizar el ejecutable bash, y pasa la interpretación del script al intérprete bash localizado. Esto plantea el mismo problema: ¿y si env no se encuentra en /usr/bin? Afortunadamente, esta ha sido una ubicación acordada para el programa env durante décadas, por lo que los guiones escritos de esta manera son portátiles en más máquinas.

---

1. El administrador, o usuario root, a veces también se llama el “superusuario”. Esto se sabe que va a la cabeza de algunos administradores.
   
2. Los shells tcsh y csh no utilizan la variable de entorno $PATH. En cambio, buscan en una variable shell llamada $path.
   
3. En tcsh y csh, la aproximación más cercana a la cual es donde, aunque que también puede funcionar.
   
4. El comando correspondiente para establecer la variable tcsh o csh $path es: set path = (“$HOME/local/bin” $path).
   
5. Los archivos correspondientes para los shells tcsh y csh son .login y .cshrc, respectivamente.