Почему chmod 777 -R / оставляет систему непригодной для использования?


52

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



2
Я думаю, что это не сбой, а просто прервать процесс загрузки в какой-то момент. Если бы вы посмотрели /var/log/syslog, вы бы даже выяснили причину.
Привет, Ангел,

7
Важно знать, что даже если бы это не сломало вещи, оно не "давало бы разрешение всем что-либо делать". По-прежнему будет большое количество действий, которые может выполнить только «root» (точнее, процесс с эффективным нулевым UID).
Звол

6
@ Глен, если под «связанным» вы подразумеваете «точный дубликат, показывающий, почему мы должны иметь возможность помечать как дублирующие на разных сайтах», тогда точно! отличная ссылка. ;)
underscore_d

4
Мне бы очень хотелось услышать историю о том, что ты задал этот вопрос.
Деви Морган

Ответы:


104

Есть несколько причин.

Во-первых, в дополнение к обычным разрешениям на чтение / запись / выполнение существуют некоторые другие биты, которые содержат разрешения для файлов. Наиболее заметно setuidи setgid. Когда программа с одним из этих установленных битов разрешения запускается, она получает «эффективный UID» и / или «эффективный GID» владельца программы, а не пользователя, который ее запускал. Это позволяет программам работать с большим количеством разрешений, чем пользователь, который их запускал. Он используется многими важными системными утилитами, включая suи sudo. Ваша chmodкоманда очищает эти биты, оставляя утилиты непригодными для использования.

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


41

Краткий ответ.

Система Linux требует определенных разрешений для определенных программ, таких как sudoи т. Д.

При запуске chmod 777 -R /вы стираете все разрешения и заменяете их 777. Это делает систему непригодной для использования, если вы вручную не восстановите все разрешения.

На практике это намного быстрее и проще для повторной установки.

Проблема заключается в том, что многие системные программы разработаны так, что они не запускаются, если им «не нравятся» разрешения. Это сделано из соображений безопасности.

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

Если вы действительно хотите, чтобы у всех пользователей были неограниченные разрешения в Ubuntu, вы можете добавить всех пользователей в sudoгруппу вместо изменения прав доступа к файлам и каталогам. Это будет иметь тот же эффект, но не разрушит систему.

Другой способ (очень плохой) - активировать учетную запись root и разрешить всем входить в систему как root.


11
Может быть, кто-то займет время и сделает подробный ответ ;-)
Pilot6

1
Я мог бы указать на лучший способ позволить всем делать все в этой системе, но написать углубленную статью о том, зачем каждому двоичному файлу свои специфические права доступа, настройки и флаги, слишком много, imho. ;-)
Филипп-Зьян К Ли - Стокманн

4
Системы Linux не предназначены для того, чтобы каждый мог делать все. Вы можете включить учетную запись root, и каждый может войти в систему как root для этого. Это глупо, но это путь.
Pilot6

9
Итак, Pilot6, вы хотите сказать, что системные программы были разработаны таким образом, что, если разрешение идет не так, как надо, они не могут / не могут нормально функционировать? И, пожалуйста, Pilot6, если возможно, предоставьте более глубокий ответ с примерами и объяснением, почему определенные приложения требуют ограниченных разрешений. Благодарю.
Бридж Радж Кишор

13
@Goldname Авария - это ошибка - это целый ряд программ, говорящих: «Я не могу выполнять критические функции с системой в этом состоянии, поэтому я прерываю»
Шадур

32

chmod имеет тонкие нюансы.

chmod 0777ведет себя иначе, чем chmod u+rwx,g+rwx,o+rwxв том, что setuid и setgid обнуляются первым и сохраняются последним.

Вот почему система стала непригодной для использования. Вы удалили необходимый setuid из нескольких программ.

Вот список файлов setuid или setgid на моем ноутбуке Linux Fedora 23:

[root@fedora23lnvr61]# find / -perm /g+s,u+s
/var/log/journal
/var/log/journal/75e870eb13c74fbf97556a32ecf80ea2
/opt/google/chrome/chrome-sandbox
/usr/bin/rogue
/usr/bin/gnuchess
/usr/bin/locate
/usr/bin/umount
/usr/bin/lbrickbuster2
/usr/bin/gpasswd
/usr/bin/crontab
/usr/bin/fusermount
/usr/bin/su
/usr/bin/at
/usr/bin/newuidmap
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/mount
/usr/bin/chsh
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/chage
/usr/bin/chfn
/usr/bin/write
/usr/bin/newgidmap
/usr/sbin/mount.nfs
/usr/sbin/lockdev
/usr/sbin/netreport
/usr/sbin/userhelper
/usr/sbin/usernetctl
/usr/sbin/unix_chkpwd
/usr/sbin/pam_timestamp_check
/usr/libexec/kde4/kdesud
/usr/libexec/kde4/kpac_dhcp_helper
/usr/libexec/dbus-1/dbus-daemon-launch-helper
/usr/libexec/qemu-bridge-helper
/usr/libexec/openssh/ssh-keysign
/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper
/usr/libexec/utempter/utempter
/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache
/usr/libexec/Xorg.wrap
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/lib64/vte-2.90/gnome-pty-helper
/usr/lib64/virtualbox/VBoxSDL
/usr/lib64/virtualbox/VirtualBox
/usr/lib64/virtualbox/VBoxNetNAT
/usr/lib64/virtualbox/VBoxHeadless
/usr/lib64/virtualbox/VBoxNetDHCP
/usr/lib64/virtualbox/VBoxNetAdpCtl
/usr/lib64/virtualbox/VBoxVolInfo
/usr/lib64/vte/gnome-pty-helper
[root@fedora23lnvr61]# 

Я удалил десятки шумовых записей в кешах и логах.


3
Смею интересно, почему гнусесс и мошенник в этом списке?
WiseOldDuck

2
@WiseOldDuck: Я ожидаю, что в играх есть доля, чтобы они могли обновлять свой файл «рекордов», но не позволяли делать это непривилегированным пользователям.
Wallyk

3
@WiseOldDuck Как говорит Уоллик, плюс, помните, setuid не обязательно должен использовать root (а afaik setgid на самом деле не полезен для root)
StarWeaver

5
Up'd для того, чтобы потрудиться объяснить, что chmodделает, и предоставить пример свидетельства, чего очень не хватает в других местах.
underscore_d

1
Значит ли это, что chmod u+rwx,g+rwx,o+rwx -R /не сломает систему?
Деннис Джаэруддин

15

В дополнение к другим ответам: вы также удалили «липкий бит» из /tmp(который обычно имеет разрешения 1777), и это может вызвать другие неожиданные проблемы, поскольку программы смогут записывать или удалять временные файлы друг друга.

Заклепка - это специальное разрешение, которое позволяет любому пользователю создавать файлы /tmp, но позволяет только тому, кто его создал, перемещать или удалять.


4
«и это помешало бы кому-либо, кроме root, использовать каталог system / tmp». - Это не кажется правильным. Это по-прежнему позволяет любому использовать каталог system / tmp. Не нужно прилипать, если у пользователя, группы и других есть все права. Это, однако, позволило бы любому удалить файлы других.
HVd

1
Итак, Бен. Если я запускаю chmod 1777 -R /, то проблем быть не должно, так как я не очищаю этот бит? -
Бридж Радж Кишор

Спасибо @hvd - вы правы, и я немного изменил пост, чтобы отразить это.
Бен Хо

@BrijRajKishore, остается вопрос, почему вы делаете это в первую очередь. Ubuntu и входящие в него программы не предназначены для работы «без разрешения» по многим причинам. Было бы разумнее вместо "su" получить root права.
Бен Хо

1
Неизвестно, приведет ли это к аварии. Вполне возможно, что так и будет, потому что внезапно приложения смогут что-то делать с временными файлами друг друга - возможно, случайно - и это может вызвать сбой. Поскольку Ubuntu никогда не тестируется таким образом, вы, вероятно, узнаете об этом первым. :-) С другой стороны, установка бита закрепления для каждой отдельной папки в системе может вызвать много других проблем с приложениями, которые ожидали, что смогут манипулировать программами из-за групповых разрешений для папки (то есть папок с разрешениями 2777).
Бен Хо
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.