Est-il possible de provoquer une erreur de segmentation en modifiant le fichier de bibliothèque lors de l'utilisation de la bibliothèque dynamique (dlopen)?

Question

J'ai été faite test_program cela en utilisant la bibliothèque dynamique et fonctionnant en tant que démon de Linux. Le test_program contient un processus d'initialisation de code.

dlopen(libtest.so);

Normalement, se termine test_program avec sigkill ne provoque pas une erreur de segmentation (I revérifié !!)

Mais quand terminé par écrasement fichier libtest.so (par exemple. cp libtest.so /lib64/libtest.so) de segmentation de la cause défaut.

le fichier de bibliothèque accidentellement écrasé et le fichier est en fait le même libtest.so (j'ai été différé).

Je serais très reconnaissant de savoir pourquoi une erreur de segmentation se produit lorsque le fichier de bibliothèque est écrasé. Merci d'avoir lu et j'ai attaché Backtrace de corefile généré et dmesg alors s'il vous plaît laissez-moi savoir si vous avez besoin de plus d'informations.

trace (séparés):

#0 0x00007fd2c7668118 in ??() from /lib64/libgcc_s.so.1 
#1 0x00007fd2c7669019 in _Unwind_Backtrace() from /lib64/libgcc_s.so.1 
#2 0x00007fd2c73a2186 in backtrace() from /lib64/libc.so.6 
#3 0x000000000050fda8 in print_trace (sig=11, siginfo=0x7fff87da5770, context=<optimized out>) at sighandler.c:239 
#4 <signal handler called> 
#5 0x0000000000018219 in ??() 
#6 0x00007fd2c9c47a1a in _dl_fini() from /lib64/ld-linux-x86-64.so.2 
#7 0x00007fd2c72d0e69 in __run_exit_handlers() from /lib64/libc.so.6 
#8 0x00007fd2c72d0eb5 in exit() from /lib64/libc.so.6 
#9 0x000000000050d655 in end_signal (signo=<optimized out>) at 
#10 <signal handler called>test_program.c:103 

dmesg:

test_program[11817]: segfault at 18219 ip 00007fd2c7668118 sp 00007fff87da4f40 error 4 in libgcc_s-4.8.5-20150702.so.1[7fd2c7659000+15000] 

Answer 1

Normalement, se termine test_program avec SIGKILL ne provoque pas de défaut de segmentation (I revérifié !!)

SIGKILL ne peut pas être attrapé ou ignoré et empêche toute f urther l'exécution du code de l'espace utilisateur. Cela implique jamais provoque un défaut de segmentation. Peut-être que vous vouliez dire SIGTERM.

Mais quand terminé avec le fichier libtest.so écrasé (par exemple. Cp libtest.so /lib64/libtest.so) provoquent une erreur de segmentation. Le backtrace que vous collez montre comment le processus a essayé de nettoyer après lui-même, donc il ne pouvait pas avoir reçu SIGKILL. Le fichier de la bibliothèque a accidentellement été écrasé et le fichier est en réalité même libtest.so (j'étais différent).

Le fichier peut être le même, mais n'est PAS le même dans la mémoire mappée au processus. cp faire tronquer sur le fichier et écraser le contenu "restauré" l'état d'origine.

Même si l'état modifié devait rester, la fenêtre de temps entre l'écriture tronquée et la fin de l'écriture présente un potentiel d'accident: soit la zone n'est pas sauvegardée par le fichier (qui donne SIGBUS), soit le code à exécuter pas encore écrit et la zone est juste mise à zéro (SIGSEGV instantanée), ou l'instruction est partiellement écrite et ressemble à faux (SIGILL).

tl; dr ne pas faire que