Как я могу обмануть процесс, думая, что файл не существует?

У меня есть программа, которая хранит свои настройки в ~/.config/myprogramчто я использую как в интерактивном режиме, так и с системой пакетного обслуживания. При интерактивном запуске я хочу, чтобы эта программа использовала мои файлы конфигурации (и это так). Но при работе в пакетном режиме файлы конфигурации не нужны, потому что я указываю параметры командной строки, которые перезаписывают все соответствующие параметры. Кроме того, доступ к файлам конфигурации по сети увеличивает время запуска программы на несколько секунд; если файлы не существуют, программа запускается намного быстрее (поскольку каждое задание занимает около минуты, это существенно влияет на пропускную способность пакетного задания). Но поскольку я также использую программу в интерактивном режиме, я не хочу постоянно перемещать / удалять свои файлы конфигурации. В зависимости от того, когда мои пакетные задания запланированы в кластере (в зависимости от использования других пользователей),

(Кроме того: производительность сетевых файлов настолько низкая, что, вероятно, является ошибкой, но я всего лишь пользователь кластера, поэтому я могу только обойти его, а не исправлять.)

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

Как я могу обмануть отдельные экземпляры этой программы, притворившись, что мои файлы конфигурации не существуют (без изменения программы)? Я надеюсь на обертку формы pretendfiledoesntexist ~/.config/myprogram -- myprogram --various-options..., но я открыт для других решений.

Эта программа, вероятно, разрешает путь к этому файлу из $HOME/.config/myprogram. Таким образом, вы можете сказать, что ваш домашний каталог находится в другом месте, например:

HOME=/nowhere your-program

Теперь, возможно, вашей программе нужен какой-то другой ресурс в вашем домашнем каталоге. Если вы знаете, кто они, вы можете подготовить фальшивый дом для вашей программы со ссылками на необходимый ей ресурс.

mkdir -p ~/myprogram-home/.config
ln -s ~/.Xauthority ~/myprogram-home/
...
HOME=~/myprogram-home myprogram

Если все остальное терпит неудачу, напишите библиотеку-оболочку, которую вы будете использовать LD_PRELOAD, чтобы open("/home/you/my-program/config.interactive")перехватывать вызов, но через него проходил любой другой. Это работает для любого типа программы, даже сценариев оболочки, так как она будет фильтровать системные вызовы.

extern int errno;

int open(const char *pathname, int flags)
{
  char *config_path = get_config_file_path();
  if (!strstr(pathname, config_path))
  {
    return get_real_open(pathname, flags);
  }
  else
  {
    errno = ENOENT;
    return -1;
  }
}

Примечание: я не проверял этот код, и я не уверен на 100%, что эта errnoчасть работает.

Посмотрите как fakerootэто делается для звонков типа getuid(2)и stat(2).

По сути, компоновщик свяжет это приложение с вашей библиотекой, которая переопределяет openсимвол. Поскольку вы не можете использовать две разные функции, названные openв вашей собственной библиотеке, вы должны разделить ее во второй части (например get_real_open), которая, в свою очередь, будет ссылаться на исходный openвызов.

Оригинал: ./Application

Application -----> libc.so
            open()

Перехватывается: LD_PRELOAD=yourlib_wrap.so ./Application

Application -----> yourlib_wrap.so --------------> yourlib_impl.so -----> libc.so
            open()                 get_real_open()                 open()

Редактировать: По-видимому, есть ldфлаг, который вы можете включить ( --wrap <symbol>), который позволяет вам писать обертки, не прибегая к двойным ссылкам:

/* yourlib.c */
#include <stdio.h>

int __real_open(const char *pathname, int flags)

int __wrap_open(const char *pathname, int flags)
{
  char *config_path = get_config_file_path();
  if (!strstr(pathname, config_path))
  {
    /* the undefined reference here will resolve to "open" at linking time */
    return __real_open(pathname, flags);
  }
  else
  {
    errno = ENOENT;
    return -1; 
  }
}

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

Это должно быть возможно с unionfs / aufs. Вы создаете chrootсреду для процесса. Вы используете реальный каталог в качестве слоя только для чтения и помещаете пустой поверх него. Затем вы монтируете том unionfs в соответствующий каталог в chrootсреде и удаляете там файл. Процесс не увидит этого, но все остальные увидят.

Переименуйте файл конфигурации, например, в config.interactive. Создайте еще один пустой файл с именем например config.script.

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

ln -s config.interactive config

Не забудьте убрать свою ссылку позже.

Если вы точно охарактеризовали, как ваша программа использует файл конфигурации, я пропустил его. Многие программы (такие как bashи vi) проверяют файл конфигурации сразу после запуска; если файл существует, прочитайте его и закройте. Эти программы никогда не обращаются к этим файлам инициализации снова. Если ваша программа такая, читайте дальше.

Я знаю, что вы отклонили ответы, которые делают файл конфигурации действительно несуществующим (переименовывая его), но у меня есть морщинка, которую я не видел, предложенный кем-либо еще. Сделайте это, когда вы вызываете программу в пакетном режиме:

DELAY_TIME=1
REALPATH="~/.config/myprogram"
HOLDPATH="${REALPATH}.hold"

mv "$REALPATH" "$HOLDPATH"
(sleep "$DELAY_TIME"; mv "$HOLDPATH" "$REALPATH")&
myprogram

Это удаляет файл конфигурации с пути, но затем перемещает его обратно на одну секунду позже, даже если myprogramон все еще работает. Это создает очень короткое окно времени, в течение которого файл недоступен - какова вероятность того, что вы запустите программу в интерактивном режиме в течение этого окна? (Даже если вы это сделаете, вы можете просто выйти и перезапустить, и файл конфигурации, вероятно, вернется на свое место.)

Это создает условия гонки; если программе требуется слишком много времени, чтобы открыть файл, она может получить реальный файл. Если это происходит достаточно часто, что является проблемой, просто увеличьте значение DELAY_TIME.

Мне нравится ответ Стефана, но это заставит любую программу поверить, что любой файл пуст - (потому что его dentry временно указывает на файл, который на самом деле пуст) :

cat <./test.txt
###OUTPUT###
notempty

mount --bind /dev/null ./test.txt
cat <./test.txt
###NO OUTPUT###

umount ./test.txt
cat <./test.txt
###OUTPUT###
notempty

Вы также можете:

mount --bind ./someotherconfig.conf ./unwanted.conf

Если бы вы хотели.