¿Se usa el modo de permiso ejecutable S para algo?

Si agrega el bit setuid para el permiso de un archivo donde tiene permiso de ejecución, cambia el x a un s lo que significa que si ejecuta ese archivo, se ejecutará como el propietario del archivo en lugar de la persona que realmente lo ejecuta.

Pero también noté que si agrega s permiso pero eliminar x permiso cambia a una S en la lista de permisos. ¿De alguna manera esto implicaría que no podría ejecutarse pero simultáneamente se ejecutaría como propietario si pudiera ejecutarse? ¿Es así?

¿Estoy malinterpretando este permiso? ¿Para qué se usa esto? ¿Qué significa?

Respuesta aceptada:

Las cuatro combinaciones existen y son significativas.

"¿Puede ejecutarlo el propietario real de este archivo?" y “¿Quién pretenderá el sistema que está ejecutando este archivo?” son dos preguntas separadas. Las cuatro combinaciones son posibles y significativas.

Cadenas de permisos mostradas por ls -l o stat -c %A show, en la posición de ejecución del propietario (es decir, en lugar de ? en ---?------ ), cuatro caracteres diferentes, uno para cada combinación:

1. - significa que el propietario no puede ejecutar el archivo y, si lo ejecuta un no propietario, se ejecuta como ese otro usuario .
2. x significa que el propietario puede ejecutar el archivo y, si lo ejecuta un no propietario, se ejecuta como ese otro usuario .
3. S significa que el propietario no puede ejecute el archivo y, si lo ejecuta un no propietario, se ejecutará como el propietario .
4. s significa que el propietario puede ejecute el archivo y, si lo ejecuta un no propietario, se ejecutará como el propietario .

El bit setuid y los bits de ejecución son bits separados, y el modo cadena es realmente solo una forma conveniente de ver los bits de permiso, incluidos esos. Otra forma de pensarlo es:

• x o s significa que el bit de ejecución está establecido. - o S significa que no lo es.
• s o S significa que el bit setuid está establecido. - o x significa que no lo es.

De manera similar, un grupo puede o no tener permisos de ejecución en un archivo y, si se ejecuta, puede o no ejecutarse con una identidad de grupo diferente a la del usuario que lo ejecuta. Para hacer que un archivo se ejecute con la identidad de grupo de su propietario de grupo en lugar de la del usuario que lo ejecuta, establecería el bit setgid (------s--- o ------S--- ).

S no representa un bit de modo separado. Es simplemente una forma de indicar que el bit setuid (o setgid) está establecido pero el bit ejecutable correspondiente no está establecido.

$ touch foo
$ chmod u+S foo
chmod: invalid mode: ‘u+S’
Try 'chmod --help' for more information.

Puedes examinar los bits mismos.

Para ver que estos son bits separados, use el %a especificador de formato para stat en lugar de %A . Para simplificar las cosas, he desactivado todos los demás bits de modo.

$ touch a b c d
$ chmod u=,g=,o= a
$ chmod u=x,g=,o= b
$ chmod u=s,g=,o= c
$ chmod u=xs,g=,o= d
$ stat -c '%A %n' a b c d
---------- a
---x------ b
---S------ c
---s------ d
$ stat -c '%04a %n' a b c d
0000 a
0100 b
4000 c
4100 d

Eso deja en claro... si te sientes cómodo con octal. Si quieres verlo en binario (son son bits después de todo) puede convertir las representaciones:

$ stat -c '%a %n' a b c d | perl -pe 's/\d+/sprintf("%012b", oct($&))/e'
000000000000 a
000001000000 b
100000000000 c
100001000000 d

Setuid establece el ID de usuario efectivo, no el ID de usuario real.

Los bits de ejecución controlan si un intento de ejecutar un archivo puede tener éxito o no, mientras que los bits setuid/setgid controlan bajo qué identidad se ejecuta el nuevo proceso si se permite su creación. Así que no hay nada inconsistente o sorprendente en la combinación de permisos S representa (-x,+s ). Esto sería así incluso si un ejecutable que se ejecuta como su propietario porque su propietario realmente lo ejecuta funciona exactamente igual que un ejecutable que se ejecuta como su propietario porque alguien lo ejecutó pero estaba configurado. Pero no es así como funciona.

El núcleo utiliza más de un número para realizar un seguimiento de la identidad del usuario de un proceso en ejecución. Uno de esos números es el UID y otro es el EUID. Vea este artículo para más detalles. El bit setuid hace que se cambie el EUID (ID de usuario efectivo), pero el UID (ID de usuario real) sigue siendo el mismo. Un uso de esto para permitir el intercambio de señales entre procesos que comparten un UID pero tienen diferentes EUID, pero otro es que permite que un programa que está diseñado para tener su bit setuid configurado para verificar quién lo ejecutó .

Por ejemplo, passwd debe ser setuid, porque solo la raíz puede cambiar las entradas en la base de datos de contraseñas:

$ ls -l "$(command -v passwd)"
-rwsr-xr-x 1 root root 54256 May 16 19:37 /usr/bin/passwd

-rwsr-xr-x tiene r-x al final, para otros . Debido a la x , incluso los usuarios que no son root o que no pertenecen al grupo root pueden ejecutar passwd . Y tiene rws cerca del principio, para propietario . Debido a los s , el programa se ejecuta como root, incluso cuando lo ejecutan personas que no son propietarios. Pero cuando ejecutas passwd usted mismo, restablece su contraseña, no la de root.

passwd es capaz de realizar cualquier cambio en la base de datos de usuarios y contraseñas, ya que se ejecuta con el ID de usuario efectivo de root. Pero está diseñado para negarse a cambiar la contraseña de cualquier persona que no sea el usuario que la ejecutó, excepto cuando ese usuario es root, porque verifica su ID de usuario real.

Relacionado:gdomap y ¿para qué sirve?

Este es el caso de uso típico del ejecutable setuid:crear una interfaz que permita a un usuario hacer que las acciones se realicen como otro, de una manera limitada que se verifica mediante el código del ejecutable setuid. Por lo tanto, solo es seguro configurar el bit setuid (o el bit setgid) en un programa que está diseñado tener esos permisos.

Esta es la otra pieza del rompecabezas para entender por qué los permisos S Los significados no son un enigma:el poder que confiere el bit setuid no lograr lo mismo que ejecutar el programa como su propietario , incluso una vez que se haya permitido ejecutar el programa.

Comprobación de UID y EUID con una copia de id muestra cómo funciona setuid.

De acuerdo, bueno, voy a configurar el bit setuid en un ejecutable que no está diseñado para él, para mostrar cómo se ven afectadas las ID de usuario reales y efectivas.

• El ejecutable será una copia del id programa que, entre otras cosas, reporta sus identificaciones de usuario reales y efectivas. Aunque este programa no está diseñado para configurarse, tampoco está diseñado para cambiar nada en absoluto, excepto para producir resultados, por lo que es razonablemente seguro. Pero aún debe eliminarlo después. (Su copia. No el original.)
• Estamos usando una copia, no cambiar los permisos en el original. Tu no necesita usar sudo o realice cualquier acción como root para esto.
• Para ejecutarlo como otro usuario, necesita una segunda cuenta de usuario, pero puede usar su para realizar acciones como que usuario. (Por defecto, la root cuenta no le permite iniciar sesión con una contraseña, por lo que si comete un error y ejecuta su sin dar el nombre de usuario al que desea cambiar, no terminará convirtiéndose accidentalmente en root, a menos que también haya habilitado los inicios de sesión de root. Si realmente quieres usar sudo -u user en lugar de su user -c , aunque, entonces puedes.)

Mi cuenta de usuario principal se llama ek y mi segunda cuenta es ek2 . Está bien si los tuyos son diferentes. Primero, como ek , copio id al directorio actual (que está en algún lugar dentro de mi directorio de inicio):

$ type -a id
id is /usr/bin/id
$ cp /usr/bin/id .

La copia es propiedad del usuario no root que la copió, pero los permisos originales:

$ ls -l id /usr/bin/id
-rwxr-xr-x 1 ek   ek   39760 Oct  5 11:23 id
-rwxr-xr-x 1 root root 39760 Mar  2  2017 /usr/bin/id

Pasando -n a id muestra nombres en lugar de números de identificación, -u muestra el usuario (y no otra información como grupos), y -r hace que se muestre el ID de usuario real. Sin -r , -u muestra el ID de usuario efectivo. Este comportamiento se aplica completamente a la copia de id acabo de hacer.

Cuando lo ejecuto como un usuario sustituto, las identificaciones de usuario reales y efectivas cambian. Esto es parte de cómo su y sudo están escritos, y no es un mero resultado de su en sí mismo siendo raíz setuid, aunque lo es. (Es por eso que usé passwd como ejemplo de un ejecutable setuid típico, en lugar de su o sudo .) Esta es nuestra línea de base, para ver que id en el directorio actual funciona como se esperaba:

$ ./id -nu                # ek runs id, displaying the effective user
ek
$ ./id -nur               # ek runs id, displaying the real user
ek
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek2
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Ahora hago esta copia local de id setuid:

$ chmod u+s id
$ ls -l id
-rwsr-xr-x 1 ek ek 39760 Oct  5 11:42 id

Ahora, cuando lo ejecuto, su ID de usuario real sigue siendo el del usuario que lo ejecutó, mientras que su ID de usuario efectivo es el de ek incluso cuando ek2 lo ejecuta:

$ ./id -nu                # ek runs id, displaying the effective user
ek
$ ./id -nur               # ek runs id, displaying the real user
ek
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Ahora le quito los permisos ejecutables al propietario pero los dejo para todos los demás:

$ chmod u-x id
$ ls -l id
-rwSr-xr-x 1 ek ek 39760 Oct  5 11:42 id

ek2 todavía puede ejecutarlo como con ek ID de usuario efectivo, aunque ek no puedo ejecutarlo:

$ ./id -nu                # ek runs id, displaying the effective user
-bash: ./id: Permission denied
$ ./id -nur               # ek runs id, displaying the real user
-bash: ./id: Permission denied
$ su ek2 -c './id -nu'    # ek2 runs id, displaying the effective user
Password:
ek
$ su ek2 -c './id -nur'   # ek2 runs id, displaying the real user
Password:
ek2

Pero, como se muestra, esto no produjo el mismo resultado que ek realmente ejecutándolo. ek2 realmente no puedo hacer lo que ek podría hacer si ek se les permitió ejecutar el programa, a menos que el programa lo permita.

Relacionado:¿No se puede iniciar Ubuntu en Acer Aspire ES17?

(Después, ejecuté rm id para eliminar el archivo, por lo que no tendría un ejecutable setuid innecesario en mi directorio de inicio. O simplemente puede desactivar el bit setuid con chmod -s id .)