Файл, который только читаем с полномочиями пользователя root
[
] В качестве альтернативы [] скрипту[], который ожидает командную строку как строку вместо обычного массива, существует специальный режим []reptyr[]:[
] [
reptyr -L ffmpeg -v debug ... < /dev/null |& less -R
] [
] Обратите внимание, что не все версии []reptyr[] имеют рабочий вариант []-L[] и принимают []] изящно. См. мой запрос на подтягивание.[
].
Если он, как вы говорите, "должен быть запущен при загрузке на незагруженной учетной записи пользователя", то он обязательно будет иметь доступ ко всем файлам, к которым имеет доступ данная незагруженная учетная запись пользователя.
Вы можете создать специальную незагруженную учетную запись пользователя для выполнения сценария. Установите разрешения на файл с секретным ключом, чтобы только эта выделенная учетная запись пользователя могла его прочитать. Но звучит так, как будто вам нужно запустить программу под определенной ранее существовавшей учетной записью пользователя, так что это может не сработать для вас.
Есть и другие решения, например, запуск в chroot(), у которого есть доступ к секретному ключу, но жизнеспособность этого зависит от того, что он делает и к чему именно, кроме файла с секретным ключом, ему нужен доступ.
Вам не нужно будет использовать sudo в любом случае, потому что /etc/rc.local запускается от имени root, так что вы можете su напрямую использовать любую учетную запись, под которой вы в конечном счете решите запустить программу.
EDIT после разъяснения вопроса:
Она должна выполняться каждый раз, когда пользователь любого типа входит в систему.
Понятно. Это совсем не то же самое, что запускать ее только один раз при старте с помощью /etc/rc.local, как вы изначально сказали!
Лучше всего в этом случае попытаться вставить секретный ключ в двоичный файл вместо того, чтобы обращаться к нему как к внешнему файлу, иметь двоичный файл, принадлежащий root и исполняемый, но не читаемый другими пользователями (разрешения, такие как rwx--x--x). Пользователи не смогут получить доступ к ключу (если только они не скомпрометируют root в системе), но они могут запустить двоичный файл.
Если вы не можете встроить секретный ключ в двоичный файл, то вы можете сделать двоичный setuid некоторым пользователям, которые могут получить доступ к секретному ключу... но будьте внимательны при написании двоичных файлов setuid.