Некоторые двойные главные установки требуют объявления максимального размера дисплея в конфигурационном файле Xorg, /etc/X11/xorg.conf
. Создайте этот файл путем выполнения Xorg -configure
как корень (или Xorg :1 -configure
если у Вас уже есть выполнение GUI). Скопируйте сгенерированную конфигурацию в /etc/X11/xorg.conf
, затем сделайте желаемые модификации.
В Screen
раздел, необходимо объявить дисплей с общим размером по крайней мере 3 360 1 050. Screen
раздел мог бы быть похожим на это:
Section "Screen"
Identifier "Configured Screen"
Device "Configured Device"
DefaultDepth 24
SubSection "Display"
Depth 8
Virtual 3360 1050
EndSubSection
SubSection "Display"
Depth 24
Virtual 3360 1050
EndSubSection
EndSection
Из соображений безопасности Вы никогда не должны пытаться выполнить что-то с пользовательскими www-данными с большим количеством полномочий, чем они естественно имеют. Была причина, почему несколько раз назад доступ Apache был перемещен в www-данные. Если необходимо сделать что-то на машине как корень - и изменяющиеся пароли или создающие учетные записи это 'что-то' - необходимо создать интерфейс. Позвольте сценарию PHP поместить что-то где-нибудь и просканируйте это с помощью сценариев, выполняемых от корня, и обработайте его там. Вы могли f.e. создавать файл, содержащий пользователей для добавления в каталоге, где www-данные имеют доступ, и затем выполните это через корень-cronjob каждые 5 минут (или меньше) и переместите файл в сделанную папку с меткой времени для управления тем, что происходит.
Я категорически не согласен, что выполнение чего-то с выше privs от веб-сервера всегда является плохой идеей.
Проблемы безопасности из веб-приложения прибывают из доверия предоставленным пользователями данным, не из точного процесса, это использует те данные.
Другими словами, если Вы не проверяете и санируете свои данные, не более безопасно передать его корневому процессу через именованный канал, чем это должно записать сценарий обертки, чтобы обработать те данные и позволить www-пользователю-данных выполнять его через sudo.
На самом деле большая часть обработки/проверки/очистки данных должна быть сделана, прежде чем данные передаются sudo сценарию, который должен a) сделать последнюю проверку на данных и b) выполнить только операции та потребность выше privs.
На самом деле я утверждал бы, что возможно более безопасно сделать последнего, потому что это - простое решение, которое это легче понять...., чем более сложными Вы делаете что-то, тем более вероятно необходимо сделать ошибку.
Какой бы ни метод, Вы используете (именованный канал, sudo обертка, или безотносительно) решающую вещь, - то, что Вы исследуете данные пользователя, которыми снабжают, и удостоверьтесь, что это соответствует очень узко определенным критериям прежде, чем сделать что-либо с ним.
Существуют многочисленные статьи и практические руководства на безопасности CGI в сети, включая несколько здесь на stackexchange сайтах, но некоторые общие темы:
Я мог продолжить, но существует слишком много для подведения итогов в ответе здесь - безопасность 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
auth could not identify password for [www-data]
таким образом, я вполне уверен, это - сбой sudo. Я даже пытался делать систему ("sudo ls"); от PHP только, чтобы видеть, работал ли sudo. Это не сделало. Так или иначе я добавил код к/etc/sudoers, когда Вы советовали, но это все еще, кажется, не работает. Я трижды проверил путь, таким образом, это не проблема. Если это помогает, вот мой sudoers файл: pastebin.com/FNhdaJzL
– qwerty
09.09.2012, 16:12