Почему делает chmod 777-R / оставляют систему неприменимой?
Я только даю разрешение ко всем делать что-нибудь, но почему система отказывает путем предоставления полномочий только? Я только изменяю разрешение, не изменяющее файлы.
4 ответа
Есть несколько причин.
Во-первых, в дополнение к обычным разрешениям на чтение / запись / выполнение существуют некоторые другие биты, которые содержат разрешения для файлов. Наиболее заметно setuid и setgid. Когда программа с одним из этих установленных битов разрешения запускается, она получает «эффективный UID» и / или «эффективный GID» владельца программы, а не пользователя, который ее запускал. Это позволяет программам работать с большим количеством разрешений, чем пользователь, который их запускал. Он используется многими важными системными утилитами, включая su и sudo. Ваша команда chmod очищает эти биты, оставляя утилиты непригодными для использования.
Во-вторых, некоторые программы (особенно ssh) выполняют проверку работоспособности файловых разрешений и отказываются использовать файлы с разрешениями, которые они считают небезопасными. Это снижает риск того, что неосторожные администраторы случайно оставят дыры в безопасности, но делает работу с удаленными правами доступа к файлам еще более болезненной.
Короткий ответ.
система Linux требует определенных полномочий для определенных программ как sudo, и т.д.
, Когда Вы работаете chmod 777 -R /, Вы вытираете все полномочия и заменяете их 777. Это делает систему неприменимой, если Вы вручную не восстанавливаете все полномочия.
На практике это намного быстрее и легче переустановить.
проблема состоит в том, что много системных программ разработаны способ, которым они не запускают, если им "не нравятся" полномочия. Это сделано из соображений безопасности.
я думаю, что более важно объяснить, как обработать проектирование системы в paractice, чем объяснить, почему каждой программе не удается работать с несправедливостью permissons.
, Если Вы действительно хотите, чтобы у всех пользователей были неограниченные полномочия в Ubuntu, можно добавить всех пользователей к sudo группа вместо того, чтобы изменить полномочия каталога и файл. Это будет иметь тот же эффект, но не разрушит систему.
Иначе (очень плохой) должен активировать корневую учетную запись и позволить всем входить в систему как корень.
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]#
Я удалил десятки шумовых записей в кешах и журналах.
Дополнительный к другим ответам: Вы также удалили "липкий бит" от /tmp (который обычно имеет полномочия 1777), и это могло вызвать другие неожиданные проблемы, поскольку программы смогут записать в или удалить временные файлы друг друга.
липкий бит является специальным разрешением, которое, позволяя любому создать файлы в /tmp, только позволяет человеку, который создал его, чтобы переместить или удалить его.