What & ldquo; chmod 777 -R / & rdquo; делает в / var / www / html / & hellip; / & hellip; / & hellip; /? [dубликат]

У этого вопроса уже есть ответ здесь: Что делать, если я случайно запускаю команду & ldquo; chmod -R & rdquo; на системных каталогах (/, / etc, & hellip;) 7 ответов Почему / var / www не имеет chmod 777 2 ответа

К сожалению, я спешил и побежал sudo chmod 777 -R / внутри одного проекта. Должен ли я беспокоиться о том, что он начал добавлять 777-разрешение для всей моей папки, начиная с root (/)?

6
задан 27 July 2017 в 16:31

8 ответов

Должен ли я беспокоиться, что он начал добавлять 777-разрешение для всей моей папки, начиная с root (/)?

Нет, не нужно волноваться. Я могу гарантировать это, если вы использовали «sudo» перед ним или сделали «sudo -i». В противном случае он должен был показать ошибку разрешений.

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

вы можете сделать getfacl -R > permissions.txt из / в системе резервного копирования, чтобы создать список разрешений. На сломанной машине используйте живое сеанс, скопируйте файл в / и выполните setfacl --restore=permissions.txt в /, чтобы восстановить их.

Я бы посоветовал вам переустановить хотя.

12
ответ дан 18 July 2018 в 09:33

Да, вам абсолютно нужно беспокоиться

Вы выполнили sudo chmod 777 -R /, который будет проходить через всю файловую систему.

Для большинства файлов это небольшое неудобство. Для некоторых файлов это будет серьезный риск для безопасности (думаю, /etc/passwd и т. П.), Если какой-либо атакующий сумеет скомпрометировать вашу систему с помощью атаки оболочки или CGI.

Но самое главное, некоторые файлы ломаются, если они слишком открыты. Например, если вы откроете ~/.ssh/* (ваши ssh-ключи, authorized_keys, hosts ...), то ssh или sshd будут обрабатывать эти файлы, как если бы их там не было, из соображений безопасности. Это может в худшем случае означать, что вы становитесь заблокированным из своей собственной машины, если вы полагаетесь на ~/.ssh/authorized_keys для входа через ssh + Public Key. Есть также множество других программных пакетов, связанных с безопасностью, которые делают то же самое, в основном для их конфигураций в /etc или, возможно, некоторых файлов в /var.

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

4
ответ дан 18 July 2018 в 09:33

В точке, которая не была поднята,

... она начала добавлять 777-разрешение для всей моей папки, начиная с root ...

Вы не просто добавьте 777 разрешений, вы удалили setuid, setgid и липкий бит из всех файлов. Это заставит такие вещи, как sudo и su перестать работать, поскольку они полагаются на setuid для изменения пользователей.

Обратите внимание, что chmod 777 не подходит для chmod 0777. Эта восьмеричная цифра представляет собой биты, которые я только что упомянул. Например, chmod 4777, устанавливает бит setuid, очищает setgid и липкий бит и добавляет все разрешения.

В будущем я предлагаю использовать другой синтаксис chmod:

[F1]
0
ответ дан 18 July 2018 в 09:33

Если вы запустите:

readlink -f /var/www/html/../../..

Вы получите /, это значит, что вы сказали, что ваша команда была запущена на /, просто ваша система сейчас сломана, получить резервную копию ваших данных, переустановить Ubuntu.

chmod 's задание - изменить mod (бит разрешения) файлов / каталогов, а 777 означает, что каждый может читать, писать , выполните что-нибудь в вашей системе, в то же время вы удалили много других битов, таких как липкий, suid, sgid.

1
ответ дан 18 July 2018 в 09:33
Должен ли я беспокоиться, что он начал добавлять 777-разрешение для всей моей папки, начиная с root (/)?

Нет, не нужно волноваться. Я могу гарантировать это, если вы использовали «sudo» перед ним или сделали «sudo -i». В противном случае он должен был показать ошибку разрешений.

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

вы можете сделать getfacl -R > permissions.txt из / в системе резервного копирования, чтобы создать список разрешений. На сломанной машине используйте живое сеанс, скопируйте файл в / и выполните setfacl --restore=permissions.txt в /, чтобы восстановить их.

Я бы посоветовал вам переустановить хотя.

12
ответ дан 24 July 2018 в 19:22
  • 1
    Ой ! Так приятно учиться этому. Я начну этот вопрос для дальнейшего использования! – Mat'arangéÇa 27 July 2017 в 17:04
  • 2
    Оставляя каждый файл, присутствующий на вашем локальном компьютере, а не на удаленном, с потенциально поврежденными разрешениями (world-write и world-execute, что означает, что даже совершенно ненадежная учетная запись, такая как nobody, может изменить исполняемый файл любым другим пользователь может запуститься) не совсем ударит меня как адекватное исправление. – Charles Duffy 27 July 2017 в 18:44
  • 3
    О да, я согласен с этим :-) – Rinzwind 28 July 2017 в 08:37

Да, вам абсолютно нужно беспокоиться

Вы выполнили sudo chmod 777 -R /, который будет проходить через всю файловую систему.

Для большинства файлов это небольшое неудобство. Для некоторых файлов это будет серьезный риск для безопасности (думаю, /etc/passwd и т. П.), Если какой-либо атакующий сумеет скомпрометировать вашу систему с помощью атаки оболочки или CGI.

Но самое главное, некоторые файлы ломаются, если они слишком открыты. Например, если вы откроете ~/.ssh/* (ваши ssh-ключи, authorized_keys, hosts ...), то ssh или sshd будут обрабатывать эти файлы, как если бы их там не было, из соображений безопасности. Это может в худшем случае означать, что вы становитесь заблокированным из своей собственной машины, если вы полагаетесь на ~/.ssh/authorized_keys для входа через ssh + Public Key. Есть также множество других программных пакетов, связанных с безопасностью, которые делают то же самое, в основном для их конфигураций в /etc или, возможно, некоторых файлов в /var.

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

4
ответ дан 24 July 2018 в 19:22

В точке, которая не была поднята,

... она начала добавлять 777-разрешение для всей моей папки, начиная с root ...

Вы не просто добавьте 777 разрешений, вы удалили setuid, setgid и липкий бит из всех файлов. Это заставит такие вещи, как sudo и su перестать работать, поскольку они полагаются на setuid для изменения пользователей.

Обратите внимание, что chmod 777 не подходит для chmod 0777. Эта восьмеричная цифра представляет собой биты, которые я только что упомянул. Например, chmod 4777, устанавливает бит setuid, очищает setgid и липкий бит и добавляет все разрешения.

В будущем я предлагаю использовать другой синтаксис chmod:

[F1]
0
ответ дан 24 July 2018 в 19:22

Если вы запустите:

readlink -f /var/www/html/../../..

Вы получите /, это значит, что вы сказали, что ваша команда была запущена на /, просто ваша система сейчас сломана, получить резервную копию ваших данных, переустановить Ubuntu.

chmod 's задание - изменить mod (бит разрешения) файлов / каталогов, а 777 означает, что каждый может читать, писать , выполните что-нибудь в вашей системе, в то же время вы удалили много других битов, таких как липкий, suid, sgid.

1
ответ дан 24 July 2018 в 19:22
  • 1
    Но только пользовательский root может это сделать. Как обычный пользователь, не так много повреждений. Работает ли OP под root или нет? – Soren A 27 July 2017 в 16:24
  • 2
    Это эллипсы (т. Е. [F1]), а не ... Вероятно, он имел в виду, что он был в длинном подкаталоге в / var / www / html, когда он запускал команду, передав ее / в качестве аргумента. – JoL 27 July 2017 в 20:56

Другие вопросы по тегам:

Похожие вопросы: