Причина проблемы
Я намеревался добавить групповое разрешение на запись в скрытые файлы, такие как .hgignore, со следующим:
# pwd /opt # sudo chmod -R g+w .*
Проблема в том, что '..' соответствовал этому шаблону, и теперь для всей файловой системы RHEL установлено значение g + w. Непосредственные проблемы следующие:
Вопрос
Чтобы восстановить возможность удаленного входа в систему, человек, имеющий физический доступ к серверу, должен быть проинструктирован о том, как исправить систему.
Теперь возникает вопрос: для каких важных файлов и каталогов необходимо отменить разрешение для восстановления. ssh и sudo функциональность?
Примечание о «закрыто как дубликат»
Вопрос Почему "chmod -R 777 /" деструктивен? предоставляет подробные объяснения того, какой эффект может иметь рекурсивное расширение разрешений. Этот вопрос предназначен для ответа на вопрос о том, как восстановить удаленный доступ через ssh, чтобы можно было выполнить более обширное восстановление и ремонт.
Для файлов, которые являются частью пакета, вы можете узнать, что было испорчено, выполнив
rpm --verify "packagename"
где packagename - это отдельный пакет, или вы можете просмотреть вывод команды "rpm -qa"
Тогда вы сможете использовать rpm, чтобы исправить их чем-то вроде
rpm --setperm "имя пакета"
Проблема с ssh не ограничивается только файлом / etc, а также связана с папкой .ssh пользователя, с которым вы пытаетесь подключиться, с неправильными разрешениями. Обычно папка .ssh для пользователя должна быть 700, закрытые ключи должны быть 600, а все остальное может быть 644.
Папка / etc / ssh должна быть 755, в / etc / ssh закрытые ключи должны быть 600, а все остальное - 644.
Как восстановить сервер из-за неправильных разрешений в / etc?
Возможно, одним из самых простых способов будет восстановление из резервной копии. Вы ведь делаете резервные копии и проверяете процедуры восстановления, верно? :)
Если у вас нет резервной копии, которую вы можете использовать для восстановления, вам может потребоваться настроить чистую систему, которая идентична виртуальной машине, а затем исправить разрешения на хосте на основе вашего сервера, сравнив их.
Если у вас есть заведомо исправный сервер, запуск на нем что-то вроде следующего может помочь вам восстановить его. (Предполагает рекурсивную возможность подстановки (zsh), вместо этого можно использовать find с -exec / xargs):
for i in /etc/**/*; do
perm=$(stat "$i" -c "%a")
ssh root@badServerHostName "chmod $perm $i"
done
Может быть пара подкаталогов, чтобы исключить другие, которые могут добавить ... Rsync было бы лучше, если бы он мог только разрешения, но я не думаю, что это возможно.
Если у вас есть резервная копия, LVM и достаточно места, вы можете сделать следующее:
1. восстановите резервную копию на новом временном уровне (смонтируйте ее под / oldperm)
2. сделайте что-то вроде следующего псевдокода:
foreach oldfile in /oldperm/* {
newf = strip "/oldperm" from oldfile
chmod --reference=oldfile newf
}
Вы можете восстановить частично, как и все в / etc, если у вас есть проблемы с пространством. Этот трюк основан на флаге chmod --reference, который принимает в качестве шаблона другой файл и согласовывает аргумент с учетом разрешений.
Таким образом, вы восстанавливаете только старые перма без изменения содержимого файлов.