LINUX.ORG.RU

различить процесс и поток


0

0

дано: библиотека, попавшая по LD_PRELOAD. каким вызовом можно (если можно) отличить поток от процесса? только смотреть parent pid и на основе этого? а вдруг это форк всё-таки, а не клон?

или так: есть ли простой и вменяемый способ перехватить syscall? который int 80h, а не syscall() из glibc.

anonymous
Ответ на: комментарий от klalafuda

> найти и пропатчить PLT? и все сисколы ваши.

ps: естественно, это в надежде, что никто не вызывает int80 напрямую. что в принципе достаточно хорошее предположение.

// wbr

klalafuda ★☆☆
()


ну или посмотреть что творится в /proc/<pid>/task. к примеру, у головного потока tgid равен его pid, в то время как у дочерних потоков это не так и tgid равен pid-у головного потока.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

тогда я и без патчингов могу на syscall() сесть и на остальные куски glibc, как сейчас и сделано. внедрение то не «на лету», а как раз через LD_PRELOAD. а вот гарантии того, что не используется pthreads — нет. грузить их в каждую программу не хочу (либа задумывается как system-wide, нечто a-la libsafety; однако же надо кое-что иногда подчитывать из файла и обновлять структуры в памяти; структуры отдельные и разные для каждого процесса, но общие для потоков одного процесса).

anonymous
()
Ответ на: комментарий от anonymous


если бы месье описал простыми и понятными словами, что же он всё таки хочет получить в конечном итоге, он бы, возможно, сэкономил массу времени.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

> если бы месье описал простыми и понятными словами, что же он всё таки хочет получить в конечном итоге, он бы, возможно, сэкономил массу времени.

поясню: не то, *как* он это что-то хочет сделать, но *что именно* он хочет сделать.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

АГА! всё, благодарю — вот этот пинок был в точку. man gettid всё рассказало:

In a single-threaded process, the thread ID is equal to the process ID (PID, as returned by getpid(2)). In a multithreaded process, all threads have the same PID, but each one has a unique TID.

тестовый код это подтвердил (странно, правда? %-). жить стало намного легче. а всего-то надо было внимательней man clone почитать, блин.

anonymous
()
Ответ на: комментарий от klalafuda

всё, tnx. мсье уже решил проблему с твоей помощью. собственно, мсье надо было иметь pid и уникальные tid, и мсье тупое — оно не знало про SYS_gettid. уже узнало путём пинка в маны в верном направлении. %-)

anonymous
()
Ответ на: комментарий от klalafuda

если уж очень интересно — мсье делает перехватчик сокетных вызовов. примитивный user-mode firewall и соксифиер для программ без исходников/которые лень перекомпиливать. ну, понадобилось. соответственно, пытается родить MREW-решение для работы с таблицей правил. а для этого надо unique thread id. и желательно ещё было знать, какому процессу принадлежит поток.

зыж не надо тыкать в готовые решения для того же самого. мсье велосипедист, и хотел сам поковыряться. %-)

anonymous
()
Ответ на: комментарий от anonymous

> если уж очень интересно — мсье делает перехватчик сокетных вызовов. примитивный user-mode firewall и соксифиер для программ без исходников/которые лень перекомпиливать. ну, понадобилось. соответственно, пытается родить MREW-решение для работы с таблицей правил. а для этого надо unique thread id. и желательно ещё было знать, какому процессу принадлежит поток.

ну если месье желает именно через LD_PRELOAD, то можно поковырять палочкой все те же proxychains [лёгкий вариант] или eresi [тяжёлый но бронебойный]. впрочем, внедряться через LD_PRELOAD - это не спортивно. куда как спортивнее внедриться в уже запущенный процесс через ptrace(2).

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

да у меня уже всё написано, что надо, в общем-то. только на тупых локах а-ля critical section. захотелось вот сделать поумнее. ну, и кое-что подпилить. а так я в курсе, что подобных проектов дофига и ещё чуть-чуть, начиная с того же tsocks (откуда я нагло куски и попёр). я ж говорю — это велосипед для экспериментов, в новости на главную совать не буду. %-)

>внедряться через LD_PRELOAD — это не спортивно. куда как спортивнее внедриться в уже запущенный процесс через ptrace(2)

это больше геморроя с нулевым выигрышем в итоге. можно и сисколы хватать через него, только зачем? плюс — архитектурозависимое решение получается. а при аккуратном LD_PRELOAD и более-менее аккуратном коде на архитектуры плевать, лишь бы ядро 2.6.

впрочем, такой вариант я тоже когда-то начинал пилить. бросил, муторно и ненужно. %-)

anonymous
()
Ответ на: комментарий от anonymous

> это больше геморроя с нулевым выигрышем в итоге. можно и сисколы хватать через него, только зачем? плюс — архитектурозависимое решение получается. а при аккуратном LD_PRELOAD и более-менее аккуратном коде на архитектуры плевать, лишь бы ядро 2.6.

...и приложение было слинковано динамически. со статически слинкованным приложением LD_PRELOAD по понятным причинам работать не будет. в отличие от..

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

ну да, это понятный trade-off. впрочем, сколько тех статиков? пока не встала задача статики любить — preload вполне покатит. если встанет задача… да ну её нафиг, задачу такую! всё равно же just4fun. %-)

anonymous
()
Ответ на: комментарий от nu89

в смысле «болтологией»? %-)

ОП-кун.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.