Он позволяет исполнять код в рамках разных процессов(!) одного хоста.
API довольно простое.
sys.remote_exec принимает первым аргументом pid процесса, в котором уже(!) запущен Python-интерпретатор, а второй аргумент путь до файла с Python кодом который нужно исполнить.Конечно, существуют некоторые ограничения: мажорная и минорная версии интерпретатора, из которого отправляется запрос, должны совпадать с мажорной и минорной версией целевого интерпретатора.
И конечно, целевой интерпретатор должен поддерживать эту фичу, которую можно отключить с помощью
-X disable-remote-debug или env-переменной PYTHON_DISABLE_REMOTE_DEBUG.Безопасно ли это?
Конечно нет. В названии PEP используется слово safe, но оно не про безопасность исполнения кода, а про безопасное API что б "присоединяться" к Python-процессам, что может быть полезно для дебаггеров, например для
pdb -p.Теперь о самом интересном. Как же это реализовано?
- Windows: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-writeprocessmemory
- UNIX: https://linuxman7.org/linux/man-pages/man2/process_vm_readv.2.html
- macOS: https://developer.apple.com/documentation/kernel/1402070-mach_vm_write
Все это позволяет нам писать в нужную область памяти целевого процесса.
Отлично, мы записали информацию (конкретно, путь до файла с Python кодом который нужно исполнить). Что дальше?
Теперь дело остается за целевым процессом.
Здесь у нас есть два варианта.
1) Как вы можете знать, в Python существуют обработчики сигналов. Именно в общем обработчике сигналов как раз и проверяется, нет ли у нас <входящих запросов> на выполнение кода. Если таковые есть — считываем Python код из пути что нам отправили и выполняем его.
Почему обработка подобных запросов находится в обработчике сигналов, хотя ничего из этого не относится к сигналам?
Думаю, дело в частых попытках обработать сигналы, соответственно там же мы можем и проверить входящие запросы на исполнение Python кода. Согласно PEP, код который мы отправили будет исполнен в "следующий возможный момент", что как раз и попадает под обработку сигналов.
2) В самом интерпретаторе есть обработка "внутренних запросов":
— "stop-the-world" (пауза для сборки мусора)
— обработка тех самых сигналов :)
— обработка асинхронных исключений
— запуск сборки мусора
Теперь к этому списку добавилась обработка запросов на исполнение кода.
Осталось только что б кто-то на основе этого построил RPC :)