А что именно интересует?

>>169290
Давай для начала ты:

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

>>169293
Может перестанешь указывать?

> литературы какой по файловым системам

Исходники модулей ФС в ядре. Лучшая литература.

>>169296

>Просит дать указания
>Просит перестать указывать

Ты странный.

>>169299

А ты настолько торопишься написать пост, что без стрелочек не обходишься.

мимо

А поясните мне прелесть прав доступа к файлам в линупс/UNIX ФС, пожалуйста.
Где гибкость, если я даже не могу назначить директории разные права для разных групп? Костыль acl прошу не рассматривать, а без него ограниченное хозяин-группа-остальные.

>>169303

> разные права для разных групп

Значит, пришло время создать для этих пользователей новую группу, специально для доступа к этому каталогу. В этом и суть unix-like прав доступа. Либо всё же закостылить ACL.

>>169299
Почему ты не умеешь в лексику?

>>169304
Звучит логично. Я попытаюсь достичь просветления на практической задаче.

>>169305
Потому что ты не умеешь в логику.
микрокрокодил

>>169303
С каких пор acl стали костылём?
Этот тред потрачен начиная с оп-поста, но такое заявление слишком сильно удивило.

>>169308
Требуется установка дополнительных пакетов, часть софта всё ещё не может в поддержку ACL.
ИМХО только для связок файлопомоек на Linux с Windows AD.

r>>169309

> Требуется установка дополнительных пакетов

Так можно сказать про всё, что не coreutils. А если учесть, что systemd использует acl, то acl, можно сказать, essential.

> часть софта всё ещё не может в поддержку ACL

не очень понимаю какой софт должен поддерживать acl, кроме, собственно, файловой системы и {set,get}facl.

> ИМХО только для связок файлопомоек на Linux с Windows AD.

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

>>169311
ACL следует применять только при развёртывании связки файлового хранилища на ОС Linux с Windows AD, когда есть необходимость настраивать права с Windows машинки привычными методами.

>какой софт должен поддерживать acl

Любой файловый менеджер (не объясняй, почему я должен устанавливать/проверять права в консольке). Правда дела с последнего раза, когда я интересовался, видимо стали лучше.

>>169312
Нынче разве что Thunar не умеет.

> ACL следует применять...

А какие есть альтернативы, если стандартной модели не хватает, и чем плохи acl? SELinux — это уже следующий уровень.

>>169304

>Значит, пришло время создать для этих пользователей новую группу

Падажжи.
Смотри, например, у меня есть директория /home/user/yoba, и есть две группы пользователей. Одним, скажем, я хочу разрешить все, другим — только чтение, а посторонним (лол, формально это третья группа, но пофиг) хочу вообще все права срезать. Это возможно на базовых восьмеричных правах? Группа, которая овнит файл/директорию прописывается же только одна, хоть обсоздавайся других групп для других пользователей.

>>169309
Но ведь они в официальном ядре есть, какой же это костыль?

>>169318
Тоже интересно. Может есть какие-то хитрости, позволяющие реализовать это без привлечения acl?

Но видимо acl и есть решение, коль он уже давно не "костыль" >>169319

>>169318
Создаешь две группы: yoba, yobawrite. Пользователей, которые должны писать, заносишь в обе группы. Пользователей, которые только читают, заносишь только в группу yoba.

На директорию /home/user/yoba ставишь права 0750 и присваиваешь ее группе yoba, таким образом члены группы yoba могут читать и входить в эту директорию, а весь остальной мир не может.
Создаешь директорию /home/user/yoba/yobacontent ставишь права 0775 или по желанию 2775 и группу yobawrite. Таким образом в нее могут писать члены yobawrite, а члены yoba с ее точки зрения являются всеми остальными и могут только читать. Все остальные сюда не могут попасть, так как права на /home/user/yoba ограничивают.

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

>>169321 молодец, ты только что убил ёбу

>>169319
acl никакого отношения к ядру не имеет или я что-то упускаю?. Другое дело, что оно поддерживается всеми файловыми системами и монтирование по умолчанию происходит с acl=true.

>>169325
А кто же кроме ядра может понимать назначение опции acl=true при монтировании? И кто же кроме ядра может интерпретировать эти acl-данные в файловой системе? И кто же кроме ядра может следить за выполнением прав на доступ, установленных этими данными?

>>169326
в самом деле.что-то я не соображаю.

>>169321

>На директорию /home/user/yoba ставишь права 0750
>Создаешь директорию /home/user/yoba/yobacontent

Что-то подобное я сразу нарисовал себе, но это же как-то некрасиво совсем. Например, если я хочу настроить эти права для одного и того же контента мне что, дублировать всю директорию yoba в yobawrite и потом синхронизировать? Или я могу через темную магию симлинков это как-то сделать?

>yoba в yobawrite

yoba в yobacontent
неважный_фикс

>>169330
Нет, ты весь контент хранишь в директории yobacontent.
Ну, или ты можешь придумать другую директорию в пути, которая будет принадлежать группе yoba, которая может читать, и на которую будут стоять права 0750, которые не будут давать всем остальным читать.
В данном примере возможно, что это будет директория user.

>>169332
О, да, я тормознул, пардон. Упустил из внимания вторую "ступеньку" или как это назвать.
Вообще, довольно слабое место в восьмеричных правах все эти все-никто отношения. Если мы хотим, например, запретить какой-то определенной группе пользователей доступ, то вывести их из категории "остальные", если "группа" уже занята, будет нетривиально.