Ваши ограничения ставят очень сложную проблему: каждый пользователь в системе должен иметь доступ к этому паролю (поскольку это единственный способ для пользователей получить доступ к этой базе данных) ... но они не должны (кроме случаев, когда этот скрипт запускается, и, по-видимому, только при запуске без сеанса, например, python -i, который позволил бы им установить точку останова непосредственно перед вызовом соединения и просматривать всю память, поэтому, безусловно, может смотреть на пароль).
Вы можете написать процесс-демон, который запускается от имени пользователя root (поэтому можете прочитать mymodule.conf, который вы можете сделать доступным для чтения только пользователю root) и принимать запросы, каким-то образом проверяя, что запрос поступил от «хорошего» процесса (который запускает именно тот модуль, о котором идет речь, а не интерактивный), и только потом предоставляет пароль. Это хрупко, в основном из-за необходимости определить, может ли процесс иметь точку останова, установленную в критической точке выполнения, или нет.
В качестве альтернативы, вы могли бы еще больше повысить технологические ставки, обеспечив возврат демона, а не пароля, а открытый сокет, готовый для упаковки в оболочку, совместимую с DB-API; некоторые системы Unix позволяют отправлять открытые файловые дескрипторы между несвязанными процессами (предварительное условие для этого подхода) - и, конечно, вам придется существенно переработать API-интерфейс БД на основе MySQL, чтобы разрешить скорее открытие соединения вокруг уже открытого сокета чем свежеприготовленный. Обратите внимание, что утвержденный процесс запроса, который оказывается интерактивным, все же сможет получить объект подключения после его создания и отправлять совершенно произвольные запросы - они не смогут увидеть пароль , технически, но это не слишком утешительно. Так что маловероятно, что здесь потребуются большие усилия.
Таким образом, следующая возможная архитектура заключается в передаче всего взаимодействия с БД с помощью проверяющего демона: процесс «войдет» в демона, получит подтверждение и, если все в порядке, получит прокси-соединение с (например) сервером XMLRPC, предоставляющим доступ к серверу соединение с БД и его функциональность (демон, вероятно, разветвляет каждый такой прокси-процесс сразу после считывания пароля из файла, доступного только для чтения из корня, и сразу же удаляет привилегии, просто на общем основании безопасности).
Плюс по сравнению с предыдущей альтернативой, в дополнение к, вероятно, более простой реализации, заключается в том, что прокси-сервер также будет проверять каждый запрос SQL, который собирается отправить в базу данных MySQL, и сможет проверять и подвергать цензуре эти запросы как хорошо (предположительно на основе отказа по умолчанию, опять же для общих принципов безопасности), таким образом, серьезно ограничивая количество ущерба, который может нанести «мошенническому» клиентскому процессу (работающему в интерактивном режиме с отладчиком) ... можно надеяться; -).
Да, здесь нет простых решений - но тогда проблема, которую ставят ваши ограничения, настолько далека от простой, что граничит с внутренне противоречивой невозможностью ;-). Кстати, проблема не связана исключительно с Python, это, по сути, выбор безопасной архитектуры, которая приближается к «возведению в квадрат» - жесткие противоречивые ограничения на права доступа! -)