Linux: подмена имени бинарника — какие непредсказуемые последствия?

Question

[Trotil]

Есть сложная цепочка вызовов программ (одни процессы запускают несколько других процессов).

Возникла потребность для решения проблем совместимости выполнить некоторые предварительные действия перед запуском бинарного исполняемого файла progX (его вызываю не я, а другие процессы).

mv progX progX_orig

Создаём собственный progX:

#!/bin/sh

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

path_to_dir/progX_orig $*

Такой подход вроде работает.
Тем не менее, является ли этот метод абсолютно прозрачным и безопасным с точки зрения ОС?

Вдогонку - есть ли возможность сделать в баше вызов execve, чтобы минимизировать различия? Что будет, если дочерние процессы начнут искать родительский процесс?

Answer 1

[dykky]

1. Это абсолютно нормальный подход.
2. Если вызов проги - последнее действие скрипта, то лучше делать не подпроцесс, а замещать текущий процесс прогой, что экономит немного памяти и сохраняет отношения parent-child для сигналов (т.е. после отработки скрипта родительская прога получит абсолютно такое же состояние дочернего процесса, как и до подмены проги на скрипт):

#!/bin/sh

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

exec path_to_dir/progX_orig $*

3. Параметры в прогу лучше передавать так, как они были переданы в скрипт, а конструкция $* произведёт репарсинг аргументов.
Т.е. последняя строчка, с учётом п.2, на мой взгляд, должна выглядеть так
exec path_to_dir/progX_orig "$@"

Answer 2

[Михаил Алексеев]

Зависит от того, что это за бинарник progX и кто его еще использует.

Comments

[Trotil]

Можете привести пример, когда мой метод не сработает?

[Михаил Алексеев]

Например, если в системе есть уже программы, которые запускают progX (представим, что под progX подразумевается curl), но они ожидают, что будет запущен исходный progX, а не ваша обертка.

Answer 3

[Trotil]

Возможны параноидальные проверки:

Теоретическая опасность номер 1: проверка целостности файла progX вызывающим процессом
Теоретическая опасность номер 2: проверка корректности собственного имени процессом progX_orig

Но я с таким еще не сталкивался. Интересуют более приземлённые примеры, когда процесс не пытается проверить корректность и целостность, а просто запускает цепочку процессов с параметрами, и использует межпроцессное взаимодействие между ними. Может ли в таком случае что-то сломаться?