Cette question est associée à Où est installé le fichier principal avec abrt-hook-cpp ? .
Alors que j'essayais de générer un fichier principal pour un programme qui plantait intentionnellement, au début, la génération du fichier principal semblait être bloquée par abrt-ccpp. J'ai donc essayé de modifier manuellement /proc/sys/kernel/core_pattern avec vim :
> sudo vim /proc/sys/kernel/core_pattern
Lorsque j'ai essayé d'enregistrer le fichier, vim a signalé cette erreur :
"/proc/sys/kernel/core_pattern" E667: Fsync failed
J'ai pensé qu'il s'agissait d'un problème d'autorisation, j'ai donc essayé de modifier les autorisations :
> sudo chmod 666 /proc/sys/kernel/core_pattern
chmod: changing permissions of '/proc/sys/kernel/core_pattern': Operation not permitted
Enfin, sur la base de ce post, j'ai essayé ceci :
>sudo bash -c 'echo /home/user/foo/core.%e.%p > /proc/sys/kernel/core_pattern'
Cela a fonctionné.
Sur la base de la solution de travail, j'ai également essayé celles-ci, qui ont échoué :
> echo "/home/user/foo/core.%e.%p" > /proc/sys/kernel/core_pattern
-bash: /proc/sys/kernel/core_pattern: Permission denied
>
> sudo echo "/home/user/foo/core.%e.%p" > /proc/sys/kernel/core_pattern
-bash: /proc/sys/kernel/core_pattern: Permission denied
Question :
Pourquoi est-ce que l'édition, chmod ing et rediriger echo sortie dans le fichier /proc/sys/kernel/core_pattern tout a échoué, et seule l'invocation notée de sudo bash... a pu écraser/modifier le fichier ?
Question :
Plus précisément, par rapport aux tentatives d'invocation de sudo dans les tentatives infructueuses ci-dessus :pourquoi ont-elles échoué ? Je pensais sudo exécuté la commande suivante avec le privilège root, ce qui, je pensais, vous permettait de faire n'importe quoi sous Linux.
Réponse acceptée :
Les entrées dans procfs sont gérées par un code ad hoc. Le code qui définirait les autorisations et la propriété des fichiers sous /proc/sys (proc_sys_setattr ) rejette les changements d'autorisations et de propriété avec EPERM. Il n'est donc pas possible de modifier les autorisations ou la propriété de ces fichiers, point final. De tels changements ne sont pas implémentés, donc être root n'aide pas.
Lorsque vous essayez d'écrire en tant qu'utilisateur non root, vous obtenez une erreur d'autorisation. Même avec sudo echo "/home/user/foo/core.%e.%p" > /proc/sys/kernel/core_pattern , vous essayez d'écrire en tant qu'utilisateur non root :sudo exécute echo en tant que root, mais la redirection se produit dans le shell à partir duquel sudo est exécuté, et ce shell n'a pas de privilèges élevés. Avec sudo bash -c '… >…' , la redirection est effectuée dans l'instance bash qui est lancée par sudo et qui s'exécute en tant que root, donc l'écriture réussit.
La raison pour laquelle seul root doit être autorisé à définir le kernel.core_pattern sysctl est qu'il permet de spécifier une commande et, puisqu'il s'agit d'un paramètre global, cette commande peut être exécutée par n'importe quel utilisateur. C'est en fait le cas pour tous les paramètres sysctl à des degrés divers :ce sont tous des paramètres globaux, donc seul root peut les modifier. kernel.core_pattern est juste un cas particulièrement dangereux.