¿Cómo matar un proceso iniciado con un usuario diferente sin ser root o sudoer?


20

en un entorno Linux, necesito matar un proceso que ha sido iniciado por el usuario2 si soy usuario1 sin ser sudoers o usar root. ¿Sabes si hay una manera de configurar eso al iniciar el proceso? ¿Como una lista de usuarios autorizados para matar el proceso?

El hecho es que las instancias concurrentes del mismo proceso pueden iniciarse desde diferentes usuarios, es por eso que no es conveniente para mí establecer la identificación del grupo para el proceso. Otros usuarios que no están en el grupo no podrán iniciar un segundo proceso paralelo.

Lo que tengo es una lista de usuarios autorizados para iniciar el proceso, definido en la base de datos, antes de comenzar el proceso, verifico que el usuario actual en la lista y, en caso afirmativo, empiezo el proceso con el usuario actual. Si a un segundo usuario se le permite hacer eso quiere matar el proceso, me gustaría que se le permita hacerlo, pero no quiero que sean sudoers.

Por lo tanto, estaba pensando en crear un proceso que se ejecute como root que reciba la solicitud de matar procesos de un usuario, verifique si el usuario puede iniciar / detener el proceso y lo mata.

¿Crees que podría ser la mejor solución?


Bienvenido a SO. No creo que esto sea posible ... De todos modos, esto es más adecuado para el sitio hermano de SO, serverfault.com. Es posible que migre allí pronto, sin necesidad de hacer nada.
Pekka admite GoFundMonica

¿De qué tipo de programa estamos hablando? Sería difícil en el caso general, pero en algunos casos (como apache o una aplicación que puede modificar usted mismo) sería más fácil.
Kim

Respuestas:


14

Lo siento, pero esto simplemente no es posible (eso es por diseño). Sin embargo, si los miembros de un grupo común, el usuario1 podría escribir en un archivo que el proceso del usuario2 verifica, indicando al proceso que debería finalizar.

O bien, user2 podría ejecutar algo en segundo plano que verifique un archivo y luego envíe las señales apropiadas. Usuario1 simplemente tiene que escribir en ese archivo. Esto puede ser más fácil, ya que no requeriría ninguna modificación de los programas de user2.

Convencionalmente, no, el usuario1 no puede enviar señales POSIX al proceso del usuario2.


Gracias por tu respuesta. En mi caso, de hecho, no uso el archivo pero usamos un sistema ( dim.web.cern.ch/dim ) que puede enviar la señal apropiada, luego se puede llamar a un proceso que verifica que el usuario pueda detiene el proceso y mata el proceso.

@ATelesca: uso algo muy similar para permitir a los usuarios desfavorecidos controlar / iniciar / detener máquinas virtuales Xen en una granja bastante grande. Básicamente, lo mismo.
Tim Post

9

A menos que ACL o SELinux u otra cosa tenga una mejor manera de hacerlo, la forma en que lo he visto es con un script SetUID . Como puede imaginar, son infames por ser riesgos para la seguridad.

Con respecto a su caso, digamos que procOwner es el nombre de usuario para el propietario del proceso, y userA (uid 1000), userB (uid 1201) y userC (uid 1450) son las personas a las que se les permite matar el proceso.

killmyproc.bash:

#!/bin/bash
case ${UID} in
1000|1201|1450) ;;
*) echo "You are not allowed to kill the process."
   exit 1;;
esac

kill ${PROCESS_ID}
# PROCESS_ID could also be stored somewhere in /var/run.

Luego configure el propietario y los permisos con:

chown procOwner:procGroup killmyproc.bash
chmod 6750 killmyproc.bash

Y también ponga usuarioA, usuarioB y usuarioC en el grupo procGroup.


Intenté esto, y no funcionó. El usuario no propietario obtuvo un permiso denegado en el comando kill.
Javid Jamae

1
Solo agregaría, ¿por qué no dejar que el sistema controle los permisos para el script kill? Crear un grupo a partir de userA, userB y userC, luego compartir el killscript para ese grupo y cambiarlo a g + x me parece mucho más ordenado.
Leonid Shevtsov

1
El bit setUid no está permitido en los scripts de shell, debe crear un simple programa compilado de envoltorio para ejecutarlo
el '

2

No convencionalmente: hacer que un usuario venga y mate los procesos de otra persona es la máxima vulnerabilidad de denegación de servicio.

Se puede hacer si el proceso objetivo coopera. Una forma sería monitorear un evento externo (como un archivo que se está creando en / var / tmp, o un mensaje en un socket), indicándole que se mate a sí mismo. Si no puede escribirlo para hacerlo, puede escribir un contenedor que lo inicie y luego realice el monitoreo, eliminando el proceso secundario si ocurre el evento.


1

No puedes.

Si desea compartir procesos con otros usuarios, debe iniciar el proceso con una identificación de usuario común.


1

Por supuesto, puede escribir el programa de tal manera que finalice con gracia cuando reciba una cierta señal (término usado libremente para significar "un evento predeterminado", no una señal POSIX) de una determinada (lista de) usuarios.


Las señales no tienen un campo de "usuario". Son solo señales.
LtWorf

Por eso dije "un evento predeterminado, no una señal POSIX".
drxzcl

1

Puede escribir un programa suid que solo los usuarios de un determinado grupo puedan ejecutar y que envíe la señal adecuada al proceso. Sin embargo, no estoy seguro de si querías excluir suid.


0

suid bit no funciona con scripts de bash. En mi opinión, la mejor manera es escribir un script de envoltura "killservice". Supongamos que su servicio se está ejecutando como usuario de servicio

#!/bin/bash
sudo -u serviceuser /usr/bin/killserviceworker

luego

# addgroup servicekiller
# chown root:servicekiller /usr/bin/killservice
# chmod 750 /usr/bin/killservice
# adduser bob servicekiller

entonces, solo necesita agregar una regla en / etc / sudoers para permitirles ejecutar / usr / bin / killserviceworker como usuario de servicio de usuario sin pedir una contraseña:

servicekiller        ALL = (serviceuser:serviceuser) NOPASSWD: /usr/bin/killserviceworker

killserviceworker puede verse así:

#!/bin/bash
kill ${cat /run/service.pid}
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.