Где информация о твердом / сохраненных гибких ссылках?

Я категорически не согласен, что выполнение чего-то с выше privs от веб-сервера всегда является плохой идеей.

Проблемы безопасности из веб-приложения прибывают из доверия предоставленным пользователями данным, не из точного процесса, это использует те данные.

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

На самом деле большая часть обработки/проверки/очистки данных должна быть сделана, прежде чем данные передаются sudo сценарию, который должен a) сделать последнюю проверку на данных и b) выполнить только операции та потребность выше privs.

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

Какой бы ни метод, Вы используете (именованный канал, sudo обертка, или безотносительно) решающую вещь, - то, что Вы исследуете данные пользователя, которыми снабжают, и удостоверьтесь, что это соответствует очень узко определенным критериям прежде, чем сделать что-либо с ним.

Существуют многочисленные статьи и практические руководства на безопасности CGI в сети, включая несколько здесь на stackexchange сайтах, но некоторые общие темы:

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

Я мог продолжить, но существует слишком много для подведения итогов в ответе здесь - безопасность CGI является широкой темой. Попробуйте поиск Google безопасности CGI или Проверки Вход CGI

С Ваш 'Я не забочусь, потому что это - только я использующий его' отношение к безопасности, я отчасти чувствую, что даю Вам заряженное ружье для сдувания ног с, но стреляю себе в ногу, ценный полезный опыт. Вот простой сценарий для создания учетной записи пользователя. Это требует корня privs.

Сценарий полагается на adduser, который доступен на debian и debian-полученных системах и возможно других. измените для использования useradd вместо этого, если это не находится в системе.

#! /bin/bash 

# make the script abort on any error
set -e

U="$1"
P="$2"

[ -z "$U" ] && echo "Error: No username provided" >&2 && exit 1
[ -z "$P" ] && echo "Error: No password provided" >&2 && exit 1

# simple check - only allow lower-case letters and digits in usernames.
[ "$U" !~ '^[a-z0-9]*$' ] && echo "Error: Invalid Username" >&2 && exit 1

# create user if they don't already exist
if ! getent passwd "$U" > /dev/null ; then

   # create the user using adduser, must provide the gecos field 
   # and disable the password so adduser doesn't ask for them. 
   adduser --gecos "$U" --disabled-password "$U"

   # now change the password
   echo "$U:$P" | chpasswd
else
    echo "Error: Username already exists" >&2
    exit 1
fi

Сохраните сценарий где-нибудь и сделайте его исполняемым файлом с chmod.

Чтобы позволить www-данным выполнять его как корень без пароля, отредактируйте/etc/sudoers с visudo и добавьте следующее:

Cmnd_Alias APACHEADDUSER = /path/to/makeaccount.sh

www-data ALL = NOPASSWD: APACHEADDUSER