У меня была аналогичная проблема, и я решил, что мой файл заканчивался на .conf
. Кажется, этого не требовалось в apache 2.2.
РЕДАКТИРОВАТЬ
Согласно комментарию, apache2.conf apache 2.4 содержит следующую строку: IncludeOptional sites-enabled / *. Conf
. sites-available
не имеет отношения к этому, если у вас нет символической ссылки с sites-enabled
.
Если вы хотите реализовать свой chgrp -R nobody / something
, сохранив бит setuid, вы можете использовать эти два find
команды
find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
-exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +
Параметр find ... -perm 04000
выбирает файлы с установленным битом setuid. Затем первая команда применяет chgrp
, а затем chmod
, чтобы восстановить сбитый бит setuid. Второй применяет chgrp
ко всем файлам, у которых нет бита setuid.
В любом случае, вы не хотите вызывать chgrp
или chmod
для символьных ссылок, поскольку это может повлиять на их цели, следовательно, ! -типа l
.
Очистка битов SUID и SGID на chgrp
(или chown
) вполне разумна. Это мера безопасности для предотвращения проблем с безопасностью. Для SGID (я полагаю, для исполняемых файлов) означает запуск этой программы с действующей группой владельца группы .
Если вы измените владельца группы, то с точки зрения безопасности и контроля доступа это будет нечто совершенно иное, то есть вместо работы с эффективной группой uvw
программа теперь работает с эффективной группой xyz
.
Таким образом, вы должны явно восстанавливать бит SUID или SGID при смене владельца.
Приложение: В заявлении о том, что chgrp (или chown) должен очищать только SGID (или SUID, соответственно)
С помощью chown
ing или chgrp
вы меняете безопасность для исполняемого файла, и это достаточная причина для очистки любых атрибутов повышения привилегий. Сила Unix заключается в концептуальной простоте, а безопасность Unix уже довольно сложна. С этой целью удаление SUID и SGID при любой смене владельца - это просто подстраховка - в конце концов, в истории Unix / Linux было немало уязвимостей из-за неправильных настроек SUID или SGID.
Таким образом, нет более глубокой причины, по которой Unix ведет себя таким образом, это просто консервативное дизайнерское решение.
Очистка бита setuid
, setgid
(по крайней мере, в Linux) для не-каталогов выполняется ядром после Системный вызов chown ()
выполняется chgrp
, а не самим chgrp
. Так что единственный способ - восстановить его потом.
Это также очищает возможности безопасности.
Итак, в GNU Linux:
chown_preserve_sec() (
newowner=${1?}; shift
for file do
perms=$(stat -Lc %a -- "$file") || continue
cap=$(getfattr -m '^security\.capability$' --dump -- "$file") || continue
chown -- "$newowner" "$file" || continue
[ -z "$cap" ] || printf '%s\n' "$cap" | setfattr --restore=-
chmod -- "$perms" "$file"
done
)
И запустите (как root
):
chown_preseve_sec :newgroup file1 file2...
, чтобы изменить группу, пытаясь сохранить разрешения.
Рекурсивно, вы могли бы сделать:
# save permissions (and ACLs). Remove the "# owner" and "# group" lines
# to prevent them being restored!
perms=$(getfacl -RPn . | grep -vE '^# (owner|group): ')
# save capabilities
cap=$(getfattr -Rhm '^security\.capability$' --dump .)
chgrp -RP nobody .
# restore permissions, ACLs and capabilities
printf '%s\n' "$perms" | setfacl --restore=-
[ -z "$cap" ] || printf '%s\n' "$cap" | setfattr -h --restore=-
(все при условии, что в противном случае ничего не испортилось с файлами одновременно).
Как обычно, в админке есть много способов.
Предлагаемое мной решение выглядит следующим образом:
cd /home/me
getfacl -R /whatever > whatever-permissions.org 2> /dev/null
# A) change lines starting with # group: root
# to # group: whatineed
sed 's/^# group: root/# group: whatineed/g' whatever-permissions.org > whatever-permissions.new
# B) change lines with group::x.y
# to group::xwy
# (where x, y mean: whatever was there before)
sed 's/^group::\(.\).\(.\)/group::\1w\2/g' whatever-permissions.new > whatever-permissions.new
cd /
setfacl --restore /home/me/whatever-permissions.new