Agregué un usuario a un grupo, pero los permisos de grupo en los archivos aún no tienen efecto

Cambié los permisos de un archivo ( chmod g+w testfile) y la ejecución ls -l testfileda:

-rwxrwxr-x 1 user1 user1 0 2011-01-24 20:36 testfile

Luego agregué un usuario a ese grupo (" / etc / group " tiene user1:x:1000:user2línea), pero no puedo editar ese archivo como user2. ¿Por qué esto es tan?

user2 necesita cerrar sesión y volver a iniciarla. Los permisos de grupo funcionan de esta manera:

• Cuando inicie sesión, sus procesos tendrán membresía de grupo en su grupo principal mencionado /etc/passwd, además de todos los grupos en los que se menciona a su usuario /etc/group. (Más precisamente, el pw_gidcampo en getpw(your_uid), además de todos los grupos de los cuales su usuario es un miembro explícito . Más allá , /etc/passwdy /etc/groupla información puede provenir de otros tipos de bases de datos de usuarios como NIS o LDAP). El grupo principal se convierte en la ID de grupo efectiva del proceso y los otros grupos se convierten en sus ID de grupo suplementarios .
• Cuando un proceso realiza una operación que requiere la pertenencia a un determinado grupo, como acceder a un archivo , ese grupo debe ser la ID de grupo efectiva o una de las ID de grupo suplementarias del proceso.

Como puede ver, su cambio en la membresía del grupo del usuario solo tiene efecto cuando el usuario inicia sesión. Para ejecutar procesos, es demasiado tarde. Por lo tanto, el usuario debe cerrar sesión y volver a iniciarla. Si eso es demasiado problema, el usuario puede iniciar sesión en una sesión separada (por ejemplo, en una consola diferente o con ssh localhost).

Bajo el capó, un proceso solo puede perder privilegios (ID de usuario, ID de grupo, capacidades). El kernel inicia el initproceso (el primer proceso después del arranque) ejecutándose como root, y cada proceso finalmente desciende de ese proceso¹. El loginproceso (o sshd, o la parte de su administrador de escritorio que lo conecta) todavía se ejecuta como root. Parte de su trabajo es eliminar los privilegios de root y cambiar a los usuarios y grupos adecuados.

Hay una sola excepción: ejecutar un programa setuid o setgid . Ese programa recibe permisos adicionales: puede elegir actuar bajo varios subconjuntos de las membresías del proceso padre más la membresía adicional en el usuario o grupo que posee el ejecutable setxid. En particular, un programa raíz setuid tiene permisos de raíz, por lo tanto, puede hacer todo²; así es como a los programas les gusta suy sudopueden hacer su trabajo.

Occasionally _{En ocasiones, hay procesos que no se derivan de init (initrd, udev) pero el principio es el mismo: comenzar como root y perder privilegios con el tiempo.}
² _{Restringiendo marcos de seguridad multinivel como SELinux.}

Es posible que necesite que el usuario2 cierre la sesión y vuelva a iniciarla (o simplemente intente ssh'ing para crear una nueva sesión de inicio de sesión). Compruebe la salida de id --groupspara mostrar los identificadores de grupo numéricos para un usuario.

sudo su $(whoami)

Esencialmente, la misma solución ssh localhost, pero utilizable sin tener un servidor ssh instalado.

Mientras tengas root. Pero si acaba de agregar un nuevo grupo y cambió los permisos, probablemente lo haga.

Hay un caso en el que el cierre de sesión del usuario no ayuda, si está utilizando la directiva ControlMaster ssh para el host. Si agrega su cuenta a un grupo, cierre sesión e inicie sesión nuevamente dentro de la misma conexión ControlMaster, la sesión aún no le mostrará una nueva membresía. Tendrá que romper por la fuerza la conexión maestra con

ssh -O exit hostname

antes de iniciar sesión nuevamente.