От имени какого пользователя запускается скрипт/приложение Linux?

От имени какого пользователя запускается скрипт/приложение Linux?

CentOS здесь, но я не думаю, что это имеет значение, потому что этодолженбыть основным вопросом Linux (я так думаю). Пытаясь установить и запустить Apache Kafka (исполняемый файл Java) на компьютере с CentOS, я задумался о вопросе, который относится к Linux в целом.

Когда вы запускаете скрипт оболочки или собственный исполняемый файл (например, java), сам скрипт/исполняемый файл определяет, от имени какого пользователя он будет запущен, или ОС определяет, от имени какого пользователя будет запущен скрипт/исполняемый файл (то есть какой пользователь будет запускать скрипт/исполняемый файл)?

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

В любом случае, почему существует общее предостережение относительно запуска процессов от имени пользователя root, а не от имени непривилегированного пользователя?

решение1

Короткий ответ: и то, и другое.

Более длинный (и гораздо более полезный) ответ: по умолчанию программа будет работать от имени пользователя, который ее запустил. Однако программа может, если она написана для этого и имеет соответствующие разрешения, получить привилегии root и/или вернуться к "системному" пользователю, чтобы запустить себя от имени. Однако эта возможность должна быть явно предоставлена ​​программе либо через процесс упаковки и установки, либо через действия, предпринятые администратором этой машины.

Общее предостережение существует, поскольку исторический опыт UNIX и Linux показал, что довольно часто программы, использующие повышенные (т. е. root) привилегии, которые им не нужны, часто делают плохие вещи для системы. Это может быть от повреждения данных до неконтролируемых процессов, которые делают остальную часть системы непригодной для использования/неотзывчивой, до процессов, которые невольно позволяют злоумышленникам получить доступ к вашей системе способами, которые вы не хотите, чтобы они это делали.

решение2

Когда выполняется «скрипт оболочки», он выполняется с разрешениями пользователя, который выполнил этот скрипт. Большинство служб (kafka, redis, nginx и т. д.), установленных с помощью менеджера пакетов (yum, apt и т. д.), устанавливают вспомогательные скрипты для облегчения управления этими службами и создают уникальных пользователей служб, связанных с этими службами (apache, redis, nginx и т. д.). Почти все эти вспомогательные скрипты изначально выполняются как root, а затем сбрасывают привилегии пользователю службы, назначенному для этой службы. Это гарантирует, что только авторизованные пользователи (т. е. пользователи, которым разрешено выполнять «sudo service kafka start») могут эффективно управлять этими службами. Это означает, что системный администратор Салли может запускать, останавливать и перезапускать kafka и nginx, в то время как разработчик Джим может быть ограничен только запуском и остановкой kafka (или чем-то подобным). Хотя администратор может создать пользователя java, на практике я этого не видел, как и пользователя ruby ​​или пользователя python. Вместо этого право собственности на услугу чаще всего закрепляется за пользователем услуги, связанным с этой конкретной услугой.

Некоторые процессы требуют запуска от имени пользователя root (обычно демон сервера ssh запускается от имени пользователя root). Другие процессы откажутся запускаться от имени пользователя root (например, postgresql).

Если вы просмотрите вспомогательный скрипт для службы в /etc/init.d/someservice (или /etc/init/someservice.conf), то фактический скрипт, который вызывает повышение или сброс привилегий, закодирован там. В качестве альтернативы, если вы вошли в систему как пользователь stephan и выполните что-то вроде /usr/sbin/redis-server -c /etc/redis.conf, а затем проверьте этот процесс из другого окна, вы увидите, что redis принадлежит stephan.

Надеюсь, это поможет.

Связанный контент