Diferencia entre propietario / root y RUID / EUID

Soy relativamente nuevo en los conceptos mencionados en la pregunta y leer sobre ellos de diferentes fuentes solo los hace más confusos. Entonces esto es lo que entendí hasta ahora:

Cuando se nos dan permisos para un archivo, se ven así:

-rwsr-xr-- 1 user1 users 190 Oct 12 14:23 file.bin

Suponemos que un usuario user2que está en el grupo usersintenta ejecutar file.bin. Si el bit setuid no estuviera establecido, esto significaría que tanto el RUID como el EUID de file.bineran iguales al UID de user2. Pero ya que se establece el bit setuid, esto significa que el RUID es ahora igual a la UID de user2, mientras que EUID es el UID del propietario del archivo, user1.

Mis preguntas son:

¿Cuál es la diferencia entre el propietario del archivo y root? ¿ rootTiene los mismos permisos que el propietario? ¿O necesitaríamos una entrada separada en la lista de permisos root?
¿Diferencia entre RUID y EUID?
- Según tengo entendido, el RUID y el EUID se aplican solo a los procesos. Si ese es el caso, ¿por qué tienen el valor de los ID de usuario?
- Si RUID es el usuario que crea el proceso, y EUID es el usuario que actualmente ejecuta el proceso, entonces la primera oración de la primera respuesta en esta pregunta no tiene ningún sentido para mí.
- ¿Entendí correctamente lo que hace el bit setuid?

— user1956190
fuente

Aquí están las respuestas:

rootsiempre tiene acceso completo a archivos y directorios. El propietario del archivo generalmente también los tiene, pero esto no siempre es cierto. Por ejemplo:
```
-r-xr----- 1 user1 users 199 Oct 14 18:42 otherfile.bin
```
user1es el propietario ; sin embargo, solo pueden leer y ejecutar , pero rootaún tienen acceso completo ( rwx ) al archivo.
RUID es la ID de usuario real y nunca (casi) cambia. Si user2inicia sesión en el sistema, el shell se inicia con su ID real establecida en user2. Todos los procesos que comiencen desde el shell heredarán la ID real user2como su ID real.

EUID es la ID de usuario efectiva , cambia para los procesos (no para el usuario) que el usuario ejecuta y que han establecido el bit setuid .

Si se user2ejecuta file.bin, el RUID será user2y el EUID del proceso iniciado será user1.

Usemos el caso de passwd:

-rwsr-xr-x 1 root root 45396 may 25  2012 /usr/bin/passwd

Cuando user2quiere cambiar su contraseña , se ejecutan /usr/bin/passwd.
El RUID será user2pero el EUID de ese proceso será root.
user2puede usar passwdpara cambiar solo su propia contraseña porque passwdcomprueba internamente el RUID y, si no es así root, sus acciones se limitarán a la contraseña del usuario real.
Es NECESARIO que el EUID se convierte rooten el caso de passwddebido a las necesidades del proceso de escritura de /etc/passwdy / o /etc/shadow.

— jcbermu
fuente

¡Gracias! Ahora todo está más claro. Sin embargo, tengo una pregunta más. El EUID solo cambia cuando un usuario ejecuta un proceso que tiene el bit setuid establecido? ¿O puede cambiar también en otra situación? Y si es así, ¿cuál es esa situación?

— user1956190

Creo que no hay otra manera que ejecutar procesos que tienen el setuidbit establecido.

— jcbermu

Un proceso que se ejecuta desde un programa "setuid" (es decir, un proceso que tiene UID efectivo ≠ UID real) puede restablecer el EUID al RUID. En algunos casos, puede alternar el EUID entre su valor inicial (es decir, el propietario del archivo del programa) y el RUID. Además, puede establecer su RUID igual a su EUID. … (Continúa)

— Scott el

(Continuación) ... procesos privilegiados (los que tienen EUID = 0, alias root) puede establecer EUID y RUID a valores arbitrarios (por ejemplo, el login, suy sudolos programas de hacerlo). En general, una vez que un proceso privilegiado cambia sus UID a valores distintos de cero, ya no tiene privilegios y no puede rootvolver a serlo . Consulte las páginas de manual setuid (2) , seteuid (2) y setreuid (2) .

— Scott

(Cont.) ... Se introdujo como un truco para resolver un problema, que posteriormente se resolvió de una manera más amplia. Podría haberse eliminado de Linux, excepto por el hecho de que tal poda rompería los programas que lo usan. Michael Kerrisk, autor de The Linux Programming Interface , dice, en su versión de la página de manual de setfsuid (2) , " setfsuid()hoy en día no es necesario y debe evitarse en nuevas aplicaciones".

— Scott,