2010-05-12 3 views
7

Фон: Я пишу сценарий для компании, которая позволит пользователям создавать учетные записи FTP через веб-интерфейс. В фоновом режиме, скрипт должен запустить кучу команд:Выполнение команд, хотя PHP/Perl-скрипты в качестве привилегированного пользователя в Linux

  • Добавить пользователя в систему (useradd)
  • Открыть и редактировать различные файлы
  • почты пользователя с помощью Sendmail

и еще несколько вещей ...

Я в основном ищу наиболее безопасный способ. Я слышал о методе setuid, методе sudo и, конечно же, запущен httpd как привилегированный пользователь. Будут проверены на достоверность введенных данных, прежде чем будут выполнены какие-либо команды (например, только буквенно-цифровые символы в именах пользователей)

Что такое метод, используемый популярными сценариями (например, webmin), так как это должно быть довольно безопасно?

ответ

5

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

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

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

+0

Единственная проблема с этим: 1) Мне нужны учетные записи, созданные сразу, я не могу ждать хрон ... что приводит к 2) Я не хочу чтобы каждый час работать cron, не повлияет ли это на сервер? – jtd

+0

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

+0

Правильно, есть несколько способов пойти на это. Каждый минута cron будет в порядке, если приемлемо подождать до одной минуты. Это не повлияет на работу сервера - большую часть времени он просто видит, что очередь пуста и выходит. Я бы, наверное, просто написал маленького демона, который проверяет очередь каждую секунду или около того. Для ваших целей достаточно одиночного процесса, не-потокового демона. Единственный недостаток - теперь вам нужно убедиться, что ваш демон всегда работает, но это довольно легко разрешимо. – timdev

2

Создайте сценарий, который принимает параметр командной строки, проверяет его и выполняет команду useradd. Добавьте пользователя httpd в файл sudoers с директивой NOLOGIN, JUST для этого одного процесса.

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

0

Начну с того, что запуск httpd как root - очень плохая идея.

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

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

Наконец, вам нужен четко определенный протокол, с помощью которого взаимодействуют пользовательский интерфейс и исполнительный механизм.

Это намного сложнее, чем использование sudo, но более безопасно (например,sudo просто позволяет пользователям выполнять определенные файлы как другой uid - вы надеетесь, что файл содержит правильную программу).

У Setuid есть те же недостатки, что и sudo с дополнительным усложнением, которое (в большинстве случаев), если оно запускает другую программу, - тогда оно будет делать это как оригинальный uid.

НТН

C.

Смежные вопросы