20. Права на файлы (RHCSA)

[@ОлегЦитцер]

Молодец. Так держать. Сейчас прохожу платные курсы под одному RU дистрибутиву, так вот для закрепления материала, решил посмотреть ролики на ютубе, т.к. не все понятно из лекций. Так ты эту тему(другие еще не смотрел) разложил лучше и бесплатно. Спасибо тебе. От лекций к лекции буду параллельно твое видео смотреть. Спасибо. Желаю большого числа подписчиков и просмотров, чтобы монета тебе капала.

[@GNULinuxPro]

Спасибо! Приятно

[@RodionTheBrave]

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

[@RodionTheBrave]

Закинул бы монетку, только не ясно куда...

[@GNULinuxPro]

Спасибо!

[@AK-md1dq]

Огромная благодарность автору за проделанную титаническую работу!!! Материал изложен очень подробно, качественно и что самое главное - последовательно. Очень приятно смотреть и читать Ваши уроки!!!

[@GNULinuxPro]

Спасибо!)

[@AlaksiejSakaou]

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

[@GNULinuxPro]

Спасибо!

[@contrack59]

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

[@WhiteBear141981]

Считаю, что это самый лучший курс по Linux на русском Ютьюбе

[@kirillkarabanov712]

Супер. Спасибо. Ждём продолжения

[@easyman333]

Спасибо!

[@inskyinsky2364]

Еще один момент, который не могу никак постигнуть. Директория shared - владелец root, группа company, права 770. Юзеры группы company заходят в нее без проблем, а юзер группы wheel не может туда попасть, даже с "sudo cd /home/company/shared" (пробовал и sudo -u root cd /home/company/shared), при этом: 1. Ошибки не появляется, он просто остается в текущей директории 2. Если залогиниться непосредственно как root, то он свободно перемещается в эту директорию. Когда кажется, что уже разобрался с sudo и правами, Линукс снова умеет удивить)

[@GNULinuxPro]

Всё дело в том, что sudo cd нельзя использовать, так как cd - это не какая-то отдельная программа в /usr/bin, а просто встроенная функция bash-а. sudo с таким не работает =)

[@qvoot]

7:41 получилось удалить потому-что есть доступ к иноде на запись родительской директории, соответственно инода редактируется > следовательно удаляется файл. Правильно понимаю?

[@andreypaichadze3201]

Мурад, приветствую. Застрял на втором задании, где нужно создать spy для группы students которой недоступен просмотр директории secret. Создал исполняемый файл spy c содержимым: #! /bin/bash ls -l /academy/secret/ Закинул его в /usr/bin/ с правами -rwsr-xr-x. Владелец и группа соответсвенно root:root. Но директорию secret он несмотря на set uid просматривать не дает(если ты конечно не root или участник групп teachers и staff ) - пишет Permission denied. Права , владелец и группа директории secret: drwxrwx--T root teachers Через setfacl еще добавлены права rwx группе staff. Не врубаюсь в чем проблема. Ось AlmaLinux 8.5

[@GNULinuxPro]

Привет! На скрипты setuid не работает. Просто скопируй ls, назови его spy и на нем suid

[@andreypaichadze3201]

upd: Пошел другим путем - spy заработал для группы students только тогда, когда добавлял через sudoers права на выполнение файла от рута или группы имеющей соответвующие права в директории

[@andreypaichadze3201]

@@GNULinuxPro Так вот где собака зарыта была))) Спасибо!

[@ВячеславПомигалов]

@@GNULinuxPro Но ведь при копировании пользователем student копия файла ls приобретает владельца student. И поменять владельца я без соотвествующих разрешений в sudo я не могу. Просто не совсем понятны условия задачи. Можно ли выполнять что-то из под sudo при создании программы spy?

[@GNULinuxPro]

@@ВячеславПомигалов создавать spy можно с точки зрения админа, а не студента

[@kopital266]

Мурад. Здравия Вам! Мне кажется в ваших лекциях вы пропустили основной фундамент различия файловых систем.Ext4, Btrfs и Xfs, ReFs, Ntfs.Как фундамент знаний. Было бы интересно их разобрать. Спасибо. zfs -?

[@GNULinuxPro]

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

[@kopital266]

@@GNULinuxPro Как базис. Мне кажется ( мое субъективное мнение) Понятие файловой системы лежит в основе. Спасибо Вам. ЛВМ интересная тема. По горячему расширять )

[@AlexMatsu-m9w]

добрый день а подскажите пожалуйста правильный синтаксис написания прав в visudo что бы пользователь мог выполнять rm только в одной директории %students ALL=(:teachers) /usr/bin/rm - так просто разрешение выполнять команду rm от другой группы спасибо.

[@GNULinuxPro]

Добрый день Просто дополните команду rm в sudoers - /usr/bin/rm /path/to/dir

[@AlexMatsu-m9w]

@@GNULinuxPro вот в том то и дело когда пишу путь до директории то перестает работать )

[@GNULinuxPro]

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

[@escobarbI4]

я раньше называл эту команду "си-аш-мод", даже и не думал, что правильно говорить "чьмод" :D

[@GNULinuxPro]

нуу, там же от слова change, ch читается как "ч". Но в целом я допускаю, что где-то мое произношение может быть неправильным, не стоит на него ориентироваться :)

[@escobarbI4]

@@GNULinuxPro мне кажется, всё зависит от уровня интеллигенции сис-админа :D

[@ИванИванов-н8м3я]

Мурад, привет! Такой вопрос, у меня есть директория shared.У нее есть GID-group1, в этой группе есть два пользователя user и user2, я поставил права 770 почему у меня не заходит user и user2 в данную директорию(cd shared/). Пишет "разрешение отклонено". У user : user wheel group1 такие группы

[@GNULinuxPro]

Привет в целом должно работать. Проверь права на вышестоящие директории и убедись, что все правильно. Если добавил пользователя в group1, нужно этим пользователем перелогиниться, чтобы права вступили в силу

[@inskyinsky2364]

Так увлекательно, что почти до двух часов ночи делал практику по этому уроку. В процессе обнаружил один нюанс. В задании №2 создаем расшаренную директорию secret для групп staff и teachers. root - владелец, "teachers" добавил в качестве группы, выставил права 1770, группе "staff" дал права через ACL. Пробую создать файл от пользователя группы teachers в директории и получаю permission denied. Иду в getfacl и там наблюдаю, что для группы почему-то стоит ограничение r-x, хотя через ls -l видно, что у директории выставлено rwxrwx--t+. В общем, пока не добавил teachers так же через ACL - ничего не завелось. Это особенность работы ACL или где-то мой косяк?

[@GNULinuxPro]

Скорее всего ты где-то ошибся. Только что перепроверил - у меня всё завелось с первого раза, т.е. не нужно было для teachers указывать acl

[@inskyinsky2364]

@@GNULinuxPro вот с утра со свежей головой проделал те же операции для новой директории - всё отлично с первого раза. И создаются файлы, и стики-бит работает. [insky@cnt ~]$ sudo mkdir /home/academy/test [insky@cnt ~]$ sudo chown :teachers /home/academy/test [insky@cnt ~]$ sudo cmod 1770 /home/academy/test [insky@cnt ~]$ sudo chmod 1770 /home/academy/test [insky@cnt ~]$ sudo setfacl -m g:staff:rwx -R /home/academy/test [insky@cnt ~]$ sudo getfacl /home/academy/test getfacl: Removing leading '/' from absolute path names # file: home/academy/test # owner: root # group: teachers # flags: --t user::rwx group::rwx group:staff:rwx mask::rwx other::--- [insky@cnt ~]$ sudo ls -l /home/academy/ total 0 drwxrwx--T+ 2 root teachers 38 Dec 6 16:37 secret drwxrwxr--+ 3 root students 21 Dec 6 13:21 students drwxrwxr--+ 3 root teachers 21 Dec 6 13:20 teachers drwxrwx--T+ 2 root teachers 6 Dec 6 16:48 test

[@inskyinsky2364]

@@GNULinuxPro но хотелось бы понять принцип работы ACL. Получается, у него приоритет выше, чем у прав, которые раздаются через chmod? Возможно, когда я первый раз раздавал права через ACL, то ввел какой-то лишний флаг, в итоге получилось правило ACL для группы r-x, которое имеет больший приоритет, чем rwx, установленный в chmod. В правильную сторону думаю?

[@GNULinuxPro]

@@inskyinsky2364 Отлично =)

[@GNULinuxPro]

@@inskyinsky2364 Нет, у стандартных unix прав приоритет выше. Можешь проверить - задай через chmod rw права для группы, а через acl убери эти права и попробуй прочесть/изменить файлы. Посмотри историю (history), что ты изменял, как задавал права. Попробуй повторить тоже самое

[@Snoop_dozhek]

я вот не понял, на экзамене по ред хат есть задачи по гетфаклу и сетфаклу?

[@GNULinuxPro]

Не могу раскрыть, какого рода вопросы есть на экзамене На сайте есть список тем, которые будут на экзамене. Там про ACL не упомянуто. Но, к примеру, долгое время на сайте не было упомянуто про autofs, хотя... Скажем так, знать тему желательно

[@ПетрЦыпин-п7и]

Прекрасно разложены всё права на директории и файлы с примерами использования. Спасибо. Только для меня не понятно использование команды chattr. Когда её нужно применять и отличие от остальных прав.

[@GNULinuxPro]

chattr не совсем про права, это больше про атрибуты файловой системы. Скажем, можно на уровне ФС так заблочить файл, что даже рут не сможет ничего изменить (пока не отменит это ограничение). Сам делал, когда хотел, чтобы юзеры не могли удалить определённые файлы даже если получили бы случайно рут права. Но кроме этого нигде не видел, чтобы кто-то его юзал. chattr много чего другого умеет

[@GNULinuxPro]

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

[@ПетрЦыпин-п7и]

@@GNULinuxPro "chattr много чего другого умеет" - хотелось бы поподробней.

[@GNULinuxPro]

@@ПетрЦыпин-п7и посмотри man chattr там различные атрибуты

[@ПетрЦыпин-п7и]

@@GNULinuxPro Большое спасибо за ответ. MAN-ы читал. Ваш ответ полностью удовлетворил мое любопытство. Достаточно фраз: "кроме этого нигде не видел, чтобы кто-то его юзал" и "хотел, чтобы файлы принадлежали юзерам, лежали в их директориях, но они не могли их удалить". Еще раз спасибо за быстрый ответ, да и вообще, за проделанную титаническую работу по курсу низкий поклон.

[@ВячеславПомигалов]

У меня есть такой вопрос по второму заданию. Разрешил пользователям группы students от имени группы teachers удалять файлы внутри secret. Но на директории secret стоит sticky bit (ранее было условие, что нельзя удалять чужое). Потому пользователи группы teachers не могут удалять в нем файлы, только самолично пользователь teacher, который и создал этот фаил. Я что-то делаю направильно? Или не так понял задание?

[@GNULinuxPro]

Нет, все верно Изначально вылетело из головы, что ставил такое условие Потом оставил как есть, чтобы ошибка в задании заставляла задуматься, попытаться найти причину, почему не работает

[@alexeyd4599]

Скажите плиз в каком файле записана инфа что для каталогов дефолтные права (до работы umask) 777, а у файла 666???

[@GNULinuxPro]

Это на уровне ядра, нельзя создавать файлы с execute правами, поэтому и создаются 666

[@alexeyd4599]

@@GNULinuxPro , спасибо это я понял. Я просто думал есть именно файл в котором указано что дефолтно для каталога 777 а для файла 666. А потом накладываем маску и получаем реальные права который прилипают к файлам и каталогам при их создании

[@GNULinuxPro]

@@alexeyd4599 не, есть просто umask, который "не до конца" работает с файлами, просто "отваливаются единички"

[@panzerft]

У меня почему-то при установке sticky bit на директорию пропадает возможность изменять файлы внутри директории членам группы, например, редактором nano. Пишет «Permission denied» при попытке сохранить. Права у группы на запись на директорию и файл есть, команда touch отрабатывает нормально. После снятия sticky bit все становится нормально, но при этом и удалить файл можно. Дистрибутив Ubuntu.

[@GNULinuxPro]

Это связано с systemd версии 241+: Включены по умолчанию sysctl fs.protected_regular и fs.protected_fifos, реализованные в ядре Linux 4.19 и запрещающие в каталогах с флагом sticky (например, /tmp) открытие чужих FIFO-каналов или файлов с флагом O_CREAT (т.е. только владелец может пересоздать свои FIFO и файлы). Активация указанных sysctl позволяет блокировать атаки, в которых злоумышленник создаёт в /tmp подставной fifo или файл, используемый другим процессом. Для отключения в /etc/sysctl.d/60-protected.conf следует изменить значения fs.protected_regular и fs.protected_fifos на "0";

[@panzerft]

@@GNULinuxPro Файл /etc/sysctl.d/60-protected.conf не существует в моей системе, но устранил проблему командой “sudo sysctl fs.protected_regular=0”. Спасибо за помощь!

[@GNULinuxPro]

Это не совсем проблема, скорее решение проблемы с уязвимостью Ваш способ делает это временно, до перезагрузки. Файл действительно не существует, его нужно создать. Либо добавить строчку "fs.protected_regular=0” в /etc/sysctl.conf или любой файл внутри директории /etc/sysctl,d, но желательно для удобства сделать отдельный файл.

[@panzerft]

@@GNULinuxPro Спасибо огромное за оперативные и подробные ответы! 👍

[@Diggertomix999]

Застрял на втором задании под звёздочкой, где нужно создать программу spy 😅 Пытался через bash, но сразу же понял, что не туда воюю, поскольку файлы по умолчанию создаются без права на запуск

[@GNULinuxPro]

Подумай, что должна делать команда spy, и не напоминает ли это что-то? Свяжи это с темой про права и.. возможно получится =)

[@Diggertomix999]

@@GNULinuxPro сдаюсь х) Единственное, что приходит в голову - каким-то образом попытаться повысить права. Ну и все действия проделываю от пользователя student. Видимо, вообще не в том направлении думаю

[@GNULinuxPro]

@@Diggertomix999 Все правильно, повысить права через файл :)

[@Diggertomix999]

@@GNULinuxPro блин, даже не представляю, как это провернуть. C ~/.bashrc игрался, с setuid пробовал что-то сделать, но все как-то мимо :\

[@GNULinuxPro]

@@Diggertomix999 setuid

[@funnyarian]

задание 3 никак не получауеся от имени группы teachers удалять файлы внутри /academy/secret вот что я по пробовал %students ALL=(:teachers) /usr/bin/rm /academy/secret/file as student sudo -g teachers /usr/bin/rm /academy/secret/file [root@alma academy]# getfacl secret/ # file: secret/ # owner: root # group: teachers # flags: --t user::rwx group::rwx group:teachers:rwx group:staff:rwx mask::rwx other::--- не знаю как -- помогите

[@GNULinuxPro]

Проверьте права, может ли группа teacher изменять директорию /academy/secret Если нет - дайте эти права Если есть, попробуйте убрать стики бит с директории и так проверить

[@funnyarian]

@@GNULinuxProесть всякие права, без sticky bit работает идеальнo

[@GNULinuxPro]

​@@funnyarian Вот sticky bit и не даёт, так как ты удаляешь не от имени владельца, а от имени группы.