rendre tous les processus d'un utilisateur donné tuables par n'importe qui

Sur un serveur partagé, j'aimerais avoir des utilisateurs de très faible priorité de sorte que chaque fois qu'un autre utilisateur (également sans privilèges root) a besoin des ressources, il peut tuer n'importe quel processus des utilisateurs de faible priorité.

Est-il possible d'autoriser quelque chose comme ça?

users not-root-user privileges

— Aslan986
source

Accordez à sudo -u le droit de tuer un utilisateur à tous les utilisateurs dont vous

— avez

J'espère vraiment que ces utilisateurs de faible priorité sont de vrais utilisateurs humains, et que vous et vos amis êtes des BOFH de race pure . Cela rend la question beaucoup plus intrigante.

— pipe

@DavidFoerster, un problème est que même lorsque le processeur n'est pas à 100%, le processus de faible priorité peut remplir le cache du processeur, etc. De même avec l'accès au disque, etc.

— Ian Ringrose

Réponses:

Accordez aux autres utilisateurs la permission de tuer les processus en tant qu'utilisateur de faible priorité via

sudo -u lowpriouser /bin/kill PID

Un utilisateur peut uniquement signaler ses propres processus, sauf s'il dispose de privilèges root. En utilisant sudo -uun utilisateur avec la configuration correcte dans le sudoersfichier peut supposer l'identité de l'utilisateur de faible priorité et tuer le processus.

Par exemple:

%killers ALL = (lowpriouser) /bin/kill

Cela permettrait à tous les utilisateurs du groupe killersde s'exécuter en /bin/killtant que lowpriouser.

Voir également le sudoersmanuel de votre système.

Sur un système OpenBSD, la même chose peut être faite via l' doasutilitaire natif avec une configuration comme

permit :killers as lowpriouser cmd /bin/kill

alors

doas -u lowpriouser /bin/kill PID

Voir les manuels pour doaset doas.conf.

— Kusalananda
source

Si vous autorisez une commande kill, vous pouvez en abuser pour envoyer des signaux sans rapport avec la terminaison à des processus arbitraires, ce qui peut être un problème de sécurité.

— forêt

@forest C'est pourquoi je ne suggère pas de donner à tout le monde la possibilité d'utiliser le compte root pour s'exécuter kill. Notez également que je suggère d'utiliser un groupe d'utilisateurs ( killers), pas tous les utilisateurs.

— Kusalananda

Mais ce que je veux dire, c'est que cela permettrait à ce groupe d'envoyer kill -HUP, pas seulement kill -TERM.

— forêt

@forest Oui. Il permet d'envoyer des signaux aux processus appartenant à lowpriouser. Si vous souhaitez restreindre les signaux à TERM, écrivez un script shell wrapper autour /bin/killet autorisez les gens à l'utiliser à la place de /bin/kill.

— Kusalananda

%killers ALL = (lowpriouser) /bin/kill -(9, 15) [0-9 ]*

— forêt

Vous ne devriez pas tuer les processus, s'ils sont de faible priorité, ils consommeront peu de ressources.

Pour leur donner une faible priorité, modifiez leur priorité manuellement ou utilisez un démon comme autonicecelui que j'ai écrit pour DEC OSF / 1 il y a de nombreuses années (c.1994) qui recherche des travaux de longue durée et réduit progressivement leur priorité plus ils s'exécutent. .

MODIFIER il existe un package appelé andqui offre cette fonctionnalité pour les Unices modernes.

— Alnitak
source

un problème est que même lorsque le processeur n'est pas à 100%, le processus de faible priorité peut remplir le cache du processeur, etc. De même avec l'accès au disque, etc.

— Ian Ringrose

@IanRingrose seules les tâches dont l'exécution a été planifiée peuvent occuper le cache ou effectuer des accès au disque.

— Alnitak

Je pense que vous abordez le problème sous le mauvais angle: si un processus est exécuté avec des paramètres de faible priorité (CPU, E / S), il ne devrait pas affecter beaucoup d'autres processus car il ne sera pas planifié pour s'exécuter. En ce qui concerne l'utilisation de la mémoire, si la mémoire principale est restreinte et que le processus n'a pas été planifié pour s'exécuter depuis longtemps (par exemple en raison de contraintes de processeur et d'E / S), ses pages «propres» sont supprimées et ses pages «sales» sont validées ou échangé et n'affecte plus les performances des autres processus.

Conclusion: avec le bon réglage de priorité et un espace d'échange suffisant, il ne devrait pas être nécessaire de supprimer les travaux de faible priorité pour faire de la «place» pour des tâches plus importantes; à la place, le noyau veillera à endormir les premiers en faveur des seconds.

— David Foerster
source

«Faible priorité» pourrait tout aussi bien signifier «pas important» sans la signification implicite «fonctionnant avec une priorité CPU réduite». Cela n'est cependant pas précisé dans la question.

— Kusalananda

@Kusalananda: Je suis d'accord que ce n'est pas explicite dans la question, mais ma réponse indique que cela devrait être en réalité.

— David Foerster

Ce n'est pas aussi simple que cela. Même un processus de faible priorité peut bloquer le système, surtout s'il a des contraintes de mémoire: selon la façon dont celles-ci sont configurées, il fera permuter le processus. L'échange provoque des E / S (qui peuvent ne pas être incluses dans le quota d'E / S du processus) et rendra également le système moins réactif par ordre de grandeur. Ensuite, vous voudrez probablement aussi qu'en général (tandis que d'autres n'ont pas besoin des ressources), le processus à faible priorité peut en fait obtenir toutes les ressources dont il a besoin (ce qui rend les limites de mémoire typiques inapplicables). Les partages CPU aident ici.

— Jonas Schäfer

@JonasWielicki, l'ancienne "méthode unix" de permutation du processus complet avait son avantage. Si je me souviens bien, HPUX peut trouver des outils pour résoudre ce problème dans les années 90.

— Ian Ringrose