LINUX.ORG.RU
решено ФорумTalks

Этот pid чей надо pid. Чем докажешь?

 ,


1

1

Ок, запустил я программу и запомнил её pid чтобы дальше подло делать с ней всякие нехорошести. Но как я могу быть уверен, что когда дело дойдёт до нехорошестей, что под данным pid-ом всё та же программа?
Ну можно, конечно, посмотреть на имя процесса, но это проверит лишь то, что запущена ТАКАЯ ЖЕ программа, но не факт что ТА ЖЕ. Т.е. это может быть другой экземпляр программы, работающий сейчас с другими данными. И трогать его не моги, за его малый pid, малый pid.

Как разруливать переиспользование pid-ов другими программами?

РЕШЕНИЕ:

 env FOO=BAR htop

Вот так можно запустить нужную программу, а потом через /proc/pid/environ проверять она ли это.



Последнее исправление: Usruser (всего исправлений: 1)

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

Ну представь ты запустил программу и ОС присвоила ей pid 100500. Ты этот pid запомнил. А потом, через некоторое время, ты захотел сделать что-то с программой. Ты же её pid для чего-то запоминал, правильно? И как ты можешь быть уверен, что программа не была давным-давно остановлена, а её pid не передан другой программе?

Usruser
() автор топика
Ответ на: комментарий от cocucka

Но что там полезного-то в моём случае? Название программы? Это не решает проблему в общем виде. Ведь мы можем запускать программы одного вида. Названия будут одинаковыми.

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

Там где-то должно быть время прошедшее с момента запуска

cocucka ★★★★☆
()

Ок, запустил я программу и запомнил её pid чтобы дальше подло делать с ней всякие нехорошести

https://habr.com/ru/post/345040/?

Но как я могу быть уверен, что когда дело дойдёт до нехорошестей, что под данным pid-ом всё та же программа?

Регулярно пасти дерево процессов и все его изменения?

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

В общем, если не ограничиваться одним pid’ом, а отрастить для своего процесса целую ветвь, то чем заковыристее и неповторимее вы ее отрастите - тем меньше вероятность, что ее повторит какой-то другой процесс

vaddd ★☆
()
Последнее исправление: vaddd (всего исправлений: 1)

Как вариант, ты можешь запускать программу с переменной окружения содержащей уникальный айдишник и через /proc смотреть переменные с которыми она была запущена.

Типа:

MY_ID=1 htop
cat /proc/<htop_pid>/environment
cocucka ★★★★☆
()
Последнее исправление: cocucka (всего исправлений: 2)
Ответ на: комментарий от cocucka

Ого! Так можно? Ничего себе. Это нужно изучить подробней.

Usruser
() автор топика

Запускаешь программу своим лаунчером (не на шелле), запоминаешь pid, выданный fork()-ом, и он будет действителен как минимум до тех пор, пока лаунчер сам не завершится, либо не сделает wait() / waitpid() - поскольку его пишешь ты - то ты это и контролируешь. В лаунчере делаешь логику ожидания превращения процесса в зомби (но без wait()), а когда он превратился - сначала удаляешь сохранённый его pid оттуда где ты его сохранил, а затем завершаешь лаунчер.

А, вот, ждать без wait() можно через waitid() с флагом WNOWAIT - тогда конец работы процесса тебе сообщат, но остатки процесса всё так же будут занимать pid.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Можно засунуть контролируемые процессы в отдельный cgroup, например.

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

Не получается так. Возможно нужно делать явный export или ещё какую shell-магию. Или это от чего-то ещё зависит. У меня не работает, хотя файл environ есть и там куча обычных переменных окружения.

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

env FOO=BAR htop

Уря! Работает! В /proc/pid/environ есть!

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

Пажжи, я только что пробовал.

В одном терминале PROC_ID="$(uuidgen)" htop

В другом cat /proc/$(pidof htop)/environ | tr '\0' '\n' | grep PROC_ID:

PROC_ID=ef8ab15b-4277-4589-8976-f9c18a121703
cocucka ★★★★☆
()
Ответ на: комментарий от cocucka

Возможно это что-то не слишком переносимое. Х.з.

Но на первых порах покатит, а там видно будет.

Usruser
() автор топика
Ответ на: комментарий от cocucka

Уязвимо к фейкам. Но если доверяем всему софту то норм.

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

Нет. Это другое. Хотя и близко.

Если говорить про трассировку состояния своих потомков родительским процессом, то и в случае традиционных pid-ов там никаких неоднозначностей не возникает: pid, возвращённый из fork-а, никуда не потеряется до тех пор, пока родитель явно его не «отпустит» с помощью wait.

Если говорить про сохранение pid-а запущенного процесса где-то в файле, то pidfd сохранить в файл нельзя, так что эту задачу он не решит. Всё равно нужен какой-то процесс-хранитель этой ссылки, который и с обычными pid-ами тоже справляется с задачей. Единственное, что тут лучше, так это то, что pidfd можно отправить другому процессу через unix-сокет, а слот дочернего процесса для wait - нельзя.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Но как я могу быть уверен, что когда дело дойдёт до нехорошестей, что под данным pid-ом всё та же программа?

До тех пор, пока существует запись в таблице процессов, нового процесса с тем же pid-ом не может быть создано. Это значит, что пока родительский процесс не сделает wait/waitpid, все норм (будет зомбачок в системе болтаться).

Само собой, если родительский процесс завершается или дочерний начинает форкаться и setsid-иться, такие штуки не работают.

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

Тогда переформулируй задачу. Кем была запущена программа, как была запущена программа, отфоркивается ли программа после запуска. В целом это всё полумеры т.к. между проверкой и непосредственно нехорошими действиями процесс может быть завершён и создастся новый с тем же пидом. Только управляющий пайп спасёт отца русской демократии

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

У меня нет ответов. Да и программы пока нет. Я просто размышляю какой БЫ она могла быть, сталкиваюсь с проблемами и ищу возможные решения. Эти решения помогут мне понять какой программа может быть. Я могу себе позволить что-то сделать не совсем корректно, а от какой-то функциональности и вовсе отказаться если она слишком уж сложно реализуется.

Usruser
() автор топика

Проблема высосана из пальца.

PIDы для новых процессов автоинкрементятся, т.е. в рамках одной сессии, у тебя не будет PIDа, меньше самого последнего, даже если ты прибьешь его родителя.

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

Угадайте какое число следует после pid_max ?

Не знаю. Но думаю что никакого, будет как с inod'ами: система просто откажется создавать новые.

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

Плюсую. Зомби-процессы не просто так изобрели. Это как раз на такой случай штука.

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

Linus года 3 назад говорил, что наверное уже стоит увеличить до 2^30 как написано в FUTEX_TID_MASK. Там сейчас ручное ограничение 4 * 1024 * 1024.

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

Даже если и больше, всё равно число конечно и они переиспользуются при исчерпании

Возможно.

Но вряд ли программа с таким огромным лагом между считыванием PID'а и «нехорошим действием с PIDом» будет адекватной ...

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

Ваше высказывание прям как никогда соответствует вашему нику :) Не обижайтесь пожалуйста, так сложилось, я хотел ответить в духе «этож не винда» и тут увидел ваш ник :) Отвечая на свой вопрос: начинаем всё сначала.
Возвращаясь к вашему ответу:

PIDы для новых процессов автоинкрементятся, т.е. в рамках одной сессии, у тебя не будет PIDа, меньше самого последнего, даже если ты прибьешь его родителя.

Вот представьте что pid_max=32768, pid родителя 32768, следующий pid будет меньше.

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

Ваше высказывание прям как никогда соответствует вашему нику

этож не винда

Верно. У нас на винде это значение равно 4.2 млрд.

Вот представьте что pid_max=32768, pid родителя 32768, следующий pid будет меньше.

Ну меньше, так меньше. Сути это не меняет.

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

Такие как он системдэ и пишут, а потом эксплоиты появляются, т.к. погромист не учёл, что pid могут повторяться

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

Правильный pid должен содержать время создания, pid прародителя, pidы всех дочерних процессов, идентификатор системы, идентификатор железа. Не благодарите.

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

Не поймут. А вот какой-нибудь хэш от логина-пароля - обобряю

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

У нас на винде

… PID довольно агрессивно переиспользуются.

В качестве эксперимента запустил Windows 10, подождал, пока он успокоится. Запустил там Firefox, получил PID 14240. Закрыл Firefox, запустил заново. Получил PID 13884.

i-rinat ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)