Могу ли я доверять своим переменным среды?

Я пишу набор утилит в bash, который имеет общую библиотеку. Каждый сценарий, который я пишу, должен иметь блок кода, определяющий путь библиотеки относительно исполняемого файла. Не сам код, а пример:

#!/bin/bash

DIR="$( cd -P "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
. $DIR/../lib/utilities/functions

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

#!/bin/bash

. $TOOLS_LIBRARY_PATH

Я мог бы использовать программу-оболочку, чтобы установить эту переменную среды, или я мог бы установить ее по своему собственному пути. Могут быть лучшие способы организовать bashнабор инструментов, но вопрос:

в том, могу ли я доверять своим переменным среды?

Это один из тех,-никогда-на самом деле-думал-о-такого рода вопросы. При программировании на других языках пути используются для поиска библиотек, (например. LD_LIBRARY_PATH, PYTHONPATH, PERLLIB, RUBYLIB, CLASSPATH, NODE_PATH), но мне никогда не приходилось останавливаться и думать о том, насколько это может быть небезопасно.

На самом деле, LD_LIBRARY_PATHимеет Почему LD_LIBRARY_PATHэто плохо , чтобы препятствовать его использованию. Переменные среды пути к библиотекам Ruby и Perl игнорируются, если вызываются их механизмы безопасности, режим$SAFEи-T(taint)соответственно.

Мои мысли на данный момент...

• Пользователь может установить TOOLS_PATH_LIBRARYбиблиотеку по своему выбору, но утилита будет работать под его uid. Они могли просто запустить свою вредоносную библиотеку напрямую с помощью bash.
• Мои инструменты sudoкое-что. Кто-то может установить свой TOOLS_PATH_LIBRARYна что-то, что использует это преимущество. Но инструменты не запускаются через sudo, они только вызывают sudoздесь и там. В любом случае пользователь должен быть sudoer, он может просто позвонить sudoнапрямую.
• Если я не могу доверять TOOLS_PATH_LIBRARY, то я не могу доверять PATH. Все вызовы программ должны использовать абсолютные пути.
• Я видел, как программы оболочки используют псевдонимы для программ, которые являются абсолютными, так что вместо вызова lsиспользуется переменная, например LS=/bin/ls. Из того, что я читал, это сделано для защиты от пользователей, переопределяющих значения программ по умолчанию как псевдонимы. См.:ПУТЬ, функции и безопасность. Рекомендации по написанию сценариев Bash. .
• Режим Perl taint рассматривает все переменные среды как "испорченные", что является предчувствием, поэтому я пытаюсь рассуждать о рисках среды.
• Один пользователь не может изменить среду другого, если этот пользователь не является пользователем root. Таким образом, меня беспокоит только пользователь, изменяющий свою среду для повышения привилегий. См.:Есть ли способ изменить переменные окружения другого процесса?

Я уклонился от этого в своего рода ответ, но я все равно опубликую его, так как это не стандартный ответ.

Обновление:Какие проблемы безопасности связаны с использованием переменных среды для указания путей к библиотекам и исполняемым файлам?