|
Есть модуль, осуществляющий хук некоторых системных вызовов, необходимо определить полный путь к образу процесса, который осуществил системный вызов. Сейчас получаю после чего делаю от получая почти всегда полный путь, но для некоторых процессов (например, chrome иногда) вместо полного пути возвращается только имя процесса. Есть ли другой способ определить полный путь к образу вызывающего процесса ? |
|
Есть такая функция proc_pid_cmdline. Я уверен, что либо она сама, либо ее содержимое будет полезно. Однако надо заметить, что получение полного имени процесса не всегда возможно. Скорее всего это врядли получится в контексте обработчика прерывания. Кирилл, а это не то же самое, что прочитать файл /proc/PID/cmdline ?
(21 Апр 14:14)
northerner
Зависит от того, что в конкретный момент вам доступнее и удобнее. Результат, очевидно, будет один и тот же.
(21 Апр 14:57)
kkvt
Да, результат, естественно тот же что и при чтении /proc/PID/cmdline. Дело в том, что он далеко не всегда содержит именно путь к исполняемому образу. За функцию спасибо, поизучаю, возможно что-то полезное для себя вытащу.
(24 Апр 22:22)
AnMakc
|
И безотносительно к модулям ядра вопрос интересный.
Насколько я понимаю, *nix-ы полный (да и неполный) путь к файлу существует (как реальность), только в момент конкретного системного вызова.
Для системы файл это i-node. Путей к нему может быть несколько (а в данный момент и вообще уже ни одного (?) (ну, в этом я не уверен, пройдет ли
unlink()для исполняющегося в этот момент файла?)).Простого способа найти путь к иноду не вижу.
Я понимаю, что Вы читаете символьный линк, в котором хотите обнаружить путь, а его там иногда нет, т.е. комментарий не совсем в тему.
Не берусь утверждать, но
unlink()к образу действующего процесса скорее всего не пройдет - области памяти, которая помечена как исполняемая, должно быть задано соответствующее отображение на файловую систему (тот самый образ процесса), впрочем это достаточно просто проверить.Для файла загрузочного модуля исполняющейся программы unlink(), rename() (rm, mv) работают, touch тоже, а вот запись в этот файл не разрешается
Собственно чего это я в своем предыдущем комментарии засомневался в этом ?
Очевидно ведь, что изменения в каталоге не связаны с изменениями самого файла.
P.S.
"Текстовый файл занят" - ну не дурацкий ли перевод "text file busy" ? Где они таких "русификаторов" набрали ?