> Звиняйте.Ничё, бывает. Я вон дальше по треду разошёлся, что ld.so загрузчик может грузить бинарии с noexec дир и только потом попробовал на практике - оказалось, что уже не может, в glibc прикрыли.
> Мой наезд был на линукс в том
> плане, что без procfs утилиты вроде top...не узнают путь до бинарника.
Да, top требует для работы чтоб 'proc' (не 'procfs', к слову, но мелочи) был замонтирован в /proc
> да и само ядро не узнают путь до бинарника.
Даже не знаю откуда у Вас такие заблуждения (неужели так сложно исходники открыть, прежде чем делать такие выводы на публику?)
Линух 4.4.x
Смотрим структуру задачи-потока на юзер-левеле (task_struct). В процессе их может быть N+1, но тогда у всех них одна и та же память (т.е. указатель на "struct mm_struct *mm")
include/linux/sched.h:
struct task_struct {
...
struct mm_struct *mm,
...
}
include/linux/mm_types.h:
struct mm_struct {
...
struct file __rcu *exe_file
...
}
И эти места в коде не обусловлены никакими #ifdef, т.е. от опций сборки не зависят.
Т.е. ядро всегда знает каков бинарь у процесса.
А файловая система 'proc' - просто использует эти данные, будучи настройкой.
$ grep CONFIG_PROC_FS /boot/config-4.4.0-64-lowlatency
CONFIG_PROC_FS=y
которая да, чаще всего включена (хотя на суперограниченных встроенных системах это можно и убрать).
> В бзде это зашивается во внутренную таблицу процессов
Ну выше видите: в Линухе тоже.
(даже не пойму: с какой стати доставать ТАКУУУЮ огромную шашку против устройства Линуха, реально не смотрев его изнутри? Берёте на понт? - так упенсурс же, все могут проверить...)
> при этом путь этот никак не изменить, а все
> что можно изменить через, скажем, argv[0] - лишь копия, а оригинал
> можно легко вывести через ps(1) или top(1).
Ну то же и в пингвине. Оригинал никуда не спрятать. И?
"Во-вторых" ушло пока что вникуда.
> В-третьих, не надо думать, что я совсем идиот
И заметьте, не я это произнёс...
> и не знаю про
> /proc/self -- для дебага этот /proc/self на*** не сдался: getpid() нужно
> смотреть, так пусть тестовая прога его печатает сама.
Да пусть. Если Вам так уж принципиально лично вызвать getpid(), а не через ФС 'proc'.
> Итого. В линуксе без procfs эта информация [о пути] _нигде_ не хранится.
См. выше и читайте прежде, чем говорить.
> Да, систем без procfs можно сказать не бывает (ТМ). И тем
> не менее, procfs это лишь опция, которую можно вырезать из ядра
> и тогда оно превращается в биомассу.
Какие-то далёкие от техники алегории...
И без PROC_FS ядро будет прекрано осведомлено кто откуда запущен.
И что-то набиомассу здесь активно начинает претендовать кто-то другой...
> В отличие от бзди, где это прописано в ... недра.
Да, внутренние файлики ядра и структуры данных называются по-разному. И всё отличие в этом вопросе.
> Всё, вопрос про /proc/pid/exe закрываем.
Да пожалуйста. Пофантазировали на тему Линукса и в люлю.
Что-то для осознающего свою правоту Вы несколько эмоциональны. К чему бы это? Или лавры Линуха на пингвине не дают покоя демону?
В бзд как-то гениально размещена таблица процесов? - нет
а в линухе? - тоже нет. Размещена и размещена.
> Хотя есть ряд вопросов по поводу '(deleted)'.
> Будет время -- поковыряю.
Ага! Обос*ать время есть, и прямо сейчас, а поднять достоверную инфу пока времени не было :) Классика.
Держите, Вам для затравочки:
запущен sleep (PID 14281)
а от рута делаем следующее:
# l /proc/14281/exe
lrwxrwxrwx 1 user user 0 фев 22 xx:09 /proc/14281/exe -> /bin/sleep
# mv /bin/sleep /bin/sleep1
# l /proc/14281/exe
lrwxrwxrwx 1 user user 0 фев 22 xx:09 /proc/14281/exe -> /bin/sleep1
Мож натолкнёт на какие мысли.
> Вот интересно, что будет при пути бинарника
> длиной PATH_MAX-1. Куда припишится '(deleted)'? :)
Досрочный ответ: выдача пути с приписанным '(deleted)' не ограничивается PATH_MAX'ом, а просто размером переданного буфера.
Просто вообще не очень ясно в чём собсно, проблема. Знать откуда был запущен процесс - ну хорошо. Структура списка процесов в Линухе покажет переименованный или удалённый путь бинаря. Но если у кого есть право удалять/переименовывать и запускать бинари - то это уже неслабый доступ. И если стоит задача наблюдать активность юзерей аж с таким уровнем доступа - то подсистема audit Вам в руки. Там каждый чих пишется: кто чего куда.
Как по мне, довольно логично: дефолтный уровень секурити - таков, надо больше - бери больше инструментов (поставить/запустить тот же auditd). Или всё сразу должно быть из коробки, невзирая надо оно или просто память жрёт? А если аналогичных инструментов не один? Возможность выбора можно считать плюсом или минусом? (необходимость думать и осознанно выбирать - тоже кому-то будет в минус)
