Это помогает с двумя вещами:
могли быть другие причины, но это - два, которые я нашел бы полезным
Две вещи:
(1) Нет абсолютно никаких преимуществ для этого. Файлы в /usr/lib
как предполагается, принадлежат корню/системе, поскольку МНОГО вещей в системе, которые принадлежат корню, зависят от них.
(2) Это - также очень хороший способ повредить Ваш system.-
Только для высказывания мнения следуйте за этим общим эмпирическим правилом:
Если в сомнении, не делайте этого.
Нет.
Если Вы не полностью понимаете причин полномочий файлов в Вашей системе, не изменяйте их.
Вообще говоря, файлы вне Вашего корневого каталога или /tmp
или обозначенные каталоги для данных должны принадлежать пользователям системы, не Вам.
Кроме того, Вы не должны писать под /usr
, за исключением /usr/local
: это резервируется для Вашего менеджера по распространению или диспетчера пакетов. Если Вы хотите установить программу в масштабе всей системы, установите ее под /usr/local
.
Тот сценарий установки похож, он пытается установить в неправильных местах. Если это пытается скопировать вещи в /usr/lib
, это повреждается. Не используйте его. Ищите пакет для своего распределения, или для лучшего сценария установки или лучших инструкций по установке. Снова, если вещи заканчиваются в /usr/lib
(в противоположность /usr/local/lib
) не проходя диспетчер пакетов, процесс установки повреждается.
/usr
АНАЛОГИЧНО ПОВРЕДИТ ВАШУ СИСТЕМУ. Не делайте этого. Худший сценарий случая, загрузите сценарий и отредактируйте его для изменения всех путей к чему-то еще перед выполнением его. Лучший случай, найдите реальный пакет, который устанавливает в Вашей пользовательской папке или/usr/local.
– Caleb
20.07.2011, 00:18
Учитывая, что sudo
/usr/bin/sudo
обычно, Вы не сможете использовать его после выполнения этого chown
команда: sudo
двоичный владелец будет собой, таким образом, Вы не доберетесь root
полномочия при выполнении его в следующий раз.
Не делайте этого.
/usr/lib/
– Thomas Ward
02.12.2014, 21:58
Нет, это небезопасно: разрешения в / usr / lib
выбраны по двум причинам:
Вы можете увидеть последнее, используя
find /usr/lib -type f -perm /7000
для поиска любой программы, используя setuid (4000), setgid (2000) или липкий бит (1000). В моем Debian7 это показывает несколько файлов:
/usr/lib/eject/dmcrypt-get-device
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/kde4/libexec/kdesud
/usr/lib/openssh/ssh-keysign
/usr/lib/libvte9/gnome-pty-helper
/usr/lib/emacs/23.4/x86_64-linux-gnu/movemail
/usr/lib/mc/cons.saver
/usr/lib/libvte-2.90-9/gnome-pty-helper
/usr/lib/utempter/utempter
/usr/lib/pt_chown
/usr/lib/evolution/camel-lock-helper-1.2
/usr/lib/policykit-1/polkit-agent-helper-1
Если вы измените владельца этих файлов, они больше не смогут выполнять задачу, для которой они предназначены. Например, gnome-pty-helper
и utempter
используются для обновления функции utmp / wtmp (предоставляя данные для w
и последний
).
Дополнительная литература: