Права доступа в Linux это первое с чем приходится знакомиться каждому новому пользователю и не все гайды дают полную картину происходящих в системе процессов.

Предисловие

На Хабре уже есть замечательная статья о правах доступа, здесь же я хотел описать то , что произойдет в вашей системе после

chmod -R 777 /

Основная часть

Для новичка может показаться что задавая и возвращая права обратно никакого ущерба системе нанести не получится, ведь мы все вернули как было. Итак с полной уверенностью в своих действия мы вводим команду и присваиваем все права всем файлам в системе. Что может пойти не так?

1. Мы навсегда распрощались с безопасностью

Чтож, это был осознанный риск и вопрос безопасности нас мало волновал останется ли система работоспособной?

2. Первая вереница ошибок

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

3. 777 на самом деле 0 777

Старший бит это биты setuid и setgid. Они необходимы для запуска файлов с определенными привелегиями. Теперь этот бит 0 , а это несомненно приведет к бесчисленному количеству ошибок.

4. /tmp и /var/tmp серьезно пострадали

В правах доступа есть sticky bit он защищает файлы от удаления людьми не владеющими ими. Это необходимо, т.к. некоторые скрипты очищают директории /tmp и без установленного sticky bit мы распрощаемся со всеми файлами в этом каталоге.

5. Теперь каждый файл в вашей системе исполняемый.

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

А можно ли починить систему?

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

Комментарии (17)


  1. Akina
    04.03.2022 08:11
    +1

    Старший бит это биты setuid и setgid.

    Бит - это биты. Какая-то не очень удачная формулировка... таки "старший байт содержит/хранит/включает биты setuid и setgid", вероятно?


  1. 13werwolf13
    04.03.2022 08:16
    +1

    А можно ли починить систему?

    Теоретически да, но скорее в очебных целях.

    ЕМНИП, на самом деле можно сделать это относительно безболезненно в некоторых дистрибутивах из коробки идёт пакет содержащий в себе файлик со списком прав на ключевые для системы файлы и директории, и скрипт который парсит и применяет их. Ну и наверное полная переустановка всех пакетов тоже всё пофиксит на уровне системы, а вот в хомяках и data директориях некоторого софта придётся прибраться руками..


    1. kosbic
      04.03.2022 11:49

      в некоторых дистрибутивах из коробки идёт пакет

      а можете написать пример такого пакета? быстрым поиском гугла я не нашел ничего подобного


      1. 13werwolf13
        04.03.2022 12:02
        -1

        Так с ходу не расскажу, напрямую не сталкивался, мне это рассказывали сколько-то лет назад, ну в opensuse видел при обновлении системы пакеты permissions и permissions-config, возможно это как раз оно.


  1. ne555
    04.03.2022 08:27
    +4

    откат на существующий backup

    А ещё пользователь не так давно перешёл на GNU/Linux, сделал свой бэкап ранее в криптоконтейнер, например, Veracrypt (том fat32/ntfs). Права все утеряны. Система восстановлена, но не работает. Фэйл.

    На полноценную статью материал не очень тянет, плюс орф.ошибки.


  1. alexander222
    04.03.2022 08:44
    +4

    Да, жизненно. Сделал так по юности на удаленном сервере, думал что безопасность не так критична, а не заморачиваться с правами сэкономит кучу времени. Спас бэкап, который удачно был снят не за долго перед этим. Второй подобный эпичный раз был немного позже, когда я выполнил chmod -R 777 на свою домашнюю директорию что бы nginx мог запускать из нее скрипты, и с удивлением обнаружил что больше не могу зайти по ssh. Благо там был добрый админ, который пообещал оторвать мне руки, и отобрать права на все сервера пока не соберу сам linux from scratch.


    1. ubriaco
      04.03.2022 12:38

      Была подобная ситуация, тоже не мог зайти по ssh. Благо дело было в облаке, примонтировал этот диск к другой машине и смог все исправить.


  1. sergiks
    04.03.2022 09:46
    -2

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

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


  1. slepnoga
    04.03.2022 10:13
    +2

    Не 0 777, а на на самом деле 00 777.

    Но если копнуть больше, то обнаужим, что место зарезервировано для 8 разрядов.

    Р.S. Вспоминая Федорчука и нынешний "контент" :(((


  1. unsignedchar
    04.03.2022 10:16

    Пожалуй, действительно, можно было бы развить эту тему. То, что эта команда сломает чуть более чем всё - нет возражений. Но можно было бы и попробовать восстановить систему - это было бы более полезно.


  1. Yak52
    04.03.2022 11:34
    +1

    rm -rf / или куда делись мои файлы


  1. saboteur_kiev
    04.03.2022 16:41

    неосторожное обращение с ,казалось бы, известной нам командой может привести к большому количеству проблем.

    Неосторожное обращение - это права администратора у неграмотного пользователя.

    С админским доступом, поломать систему можно и более простыми способами, чем запускать консоль и вводить там команды...


  1. lexore
    04.03.2022 23:54

    Фигня, без sudo ничего не случится. Вы же не логинитесь под рутом на сервер? :)


    1. Tangeman
      05.03.2022 02:49

      Я логинюсь, лет 25 уже как. Потому что в 99.9% случаев когда я логинюсь мне нужны права рута — и за всё это время ни одного фейла, как ни странно.


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


      Вообще непонятно откуда эта мантра "не логинтесь как рут" — разве что для чайников (как слабая защита от фейлов), потому что даже во времена telnet на небезопасной сетке sudo/su не спасало от прослушки и последующего вредительства.


      Впрочем, как показывает практика, от любителей стрелять себе в ногу не спасают даже бронештаны с бронеботинками — если человек не знает что делает, не выспался, или тупо повторяет инструкции шутников, в этом случае его всё равно не спасёт логин обычным пользователем если команда требует sudo.


      1. unsignedchar
        05.03.2022 09:29

        Sudo просто добавляет пару строчек в лог. От rm -rf не защищает.


    1. saboteur_kiev
      06.03.2022 01:41

      без sudo получить рутовый доступ в нормальной системе можно только в single режиме. Ибо пароль у рута должен отсутствовать по определению.


      1. unsignedchar
        06.03.2022 08:11

        Если система пару лет не обновлялась - скорее всего, найдутся и другие способы.