Board.KolibriOS.org

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

Вот я тут подумал слегка. Используя FAT колибри не сможет реализовать защиту по правам файлов, Однако можно попробовать реализовать защиту по структуре папок.
Скажем доступ для записи в системную папку имеют только приложения из этой папки, они же имеют доступ ко всем остальным папкам.
Далее следует папка общих приложений имеют права на доступ ко всему, кроме системной папки.
Затем следуют папки локальных приложений, их права ограничены доступом на запись только в собственную папку, а для работы с файлами в других папках (кроме системной), возможно использование визуальных системных сервисов (т.е. файл должен быть открыт(в смысле с правом записи) системным сервисом визуально (вручную))
Если делать поддержку многопользовательского режима то у каждого пользователя должна быть своя папка общих приложений, и защита от чтения из других аккаунтов.

Что думаете ?

Раз подняли вопрос о файлах... то нада делать каку нибуть структуру каталогов.... мне понравилась структура как Symbian сделана.
1. каталог системы (предлагаю назвать "/sys") - сейчас я сделал "%sys%", но как потом понял - это писать неудобно
2. каталог программ (предлагаю назвать "/prog") -

а файле конфигурации можно как объединить эти каталоги (на самом деле это один каталолог), так и сделать их на разных физических дисках....

Alver

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

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

Mario79

Для этого нужно чтобы ядро хранило в области своей памяти пути к программам.

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

На мой взгляд хранимая информация будет не столь уж и велика ну может пара тройка десятков килобайт. Если реализовать ее динамическое распределение не так уж и страшно.

Еще есть смутные мысли про реестр приложений и папок я честно сам не очень соображаю чего думаю, но в общем так:

Вариант 1 (Мне вообщето не нравится) - Регистрируются пути с разным уровнем доступа и регистрируются приложения с флагами доступа. Незарегистрированные пути доступны всем. Зарегистрированные только приложениям с соответствующим кодом доступа. Минус - нет полного визуального контроля за открытием файлов, в путях общего доступа. Однако системные папки защитить можно.

Вариант 2 - Регистрируется приложение с указанием уровня доступа, и, если надо, доступными (рабочими) путями. При запуске приложения система читает запись реестра и по ней создает допуск для приложения. В общем то же что и защита по папкам, но с несколько большими возможностями. Для полного счастья незарегистрированным прогам вообще запретить прямую запись.

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

SPraid


По мне структуру каталогов надо создавать исходя из того что:
1 - Будут ли в Kolibri относительные пути (сейчас их нет а стандарт '/RD/1/' используется в разных прогах)
2 - Будет ли в Kolibri в дальнейшем многопользовательский режим или нет
3 - Будут ли права доступа и как они будут работать.
4 - Будет ли Kolibri устанавливаться в один раздел с другими OS или нет.(Хотя здесь ответ по моему очевиден.)
А названия, ну можно и так, а /PRG на буковку меньше /PROG.

Тема интересная. Завтра отпишусь. Кстати, никто не в курсе, почему sysbin днем стоял?

Alver, у меня разделение доступа прежде всего основано на структуре файловой системы, а уже потом на использовании атрибутов, которых кстати в конкретной ФС может и не быть. Смысл заключается в том, чтобы в обычном режиме работы в корне держать только вирт. каталоги для отдельно взятого пользователя, которым на этапе монтирования присваиваются атрибуты, вообще никак не связанные с физической структурой файловых систем. А уже на более глубоких уровнях вложенности использовать поддерживаемые физические атрибуты, но трактовать их, если это необходимо, по особому в соответствии с общепринятыми правилами VFS. Доступ к файлам в корневом каталоге загрузочного устройства в обычном режиме не возможен (если его специально не примонтировать), т.к. после инициализации физическая составляющая корня демонтируется и остается лишь вирт. часть.

Alver
В Колибри уже есть относительные пути (начиная со вчерашнего дня )

diamond wrote:В Колибри уже есть относительные пути (начиная со вчерашнего дня)

Извини прошляпил!

Phantom-84

Доступ к файлам в корневом каталоге загрузочного устройства в обычном режиме не возможен (если его специально не примонтировать)

По мне монтаж и демонтаж устройств в папки пользователя в Kolibri будет выглядеть несколько диковато. Тем более что схема корневого каталога уже состоялась. Проще в него добавить виртуальный путь к системной папке (что уже сделано diamondом), и к папке пользователя (папке приложений и т.д.).

Описывать права доступа вполне можно и в отдельном файле в текущей папке с наследованием дочерними. Файл, для примера, можно назвать ".access" и позволить работать с ним только системе, а для прикладных приложений его вообще можно скрывать. Мне такой вариант кажется наиболее простым и прозрачнын. К тому же он не накладывает ограничений на используемую ФС.

..bw

SPraid
Пардон я не въехал что ты делал доступ к системной папке йз корня - туплю иногда.

bw
В принципе действительно прозрачно и работоспособно но сомнения насчет наследования. Скажем прграмма хочет записать файл '/hd0/1/fol1/fol2/fol3/.../folx/text.txt' и система вначале ищет файл '.access' в 'fol1', читает его, если запись разрешена, ищет файл в 'fol2', опять читает и так пока не дойдет до 'folx'. Хотя если вложенность файлов не велика можно и так, но при большом количестве файлов и сильной вложенности может и притормаживать.
хотя мне кажется проанализировать путь легче чем вычитывать файлы в каждом каталоге, хотя может я и ошибаюсь.

Подобный иерархический анализ будет присутствовать во всех системах. Я думаю что такие глубокие пути пока не ожидаются, да и в будущем они вряд ли будут сильно тормазить систему. Права определяются не при чтении файла, а при открытии, и определяться они должны сверху, ИМХО, т.е. с folx.

..bw

ага, как .htaccess на Web-сервере, если файл имеется в папке folx, то права доступа определяет он иначе смотрим каталог выше

Alver
Если анализировать в обратном порядке как предложил mistifi(ator, то будет работать намного быстрей. Другой вопрос, что приложение может захотеть получить доступ к файлу конфигурации, а если его нет, то создать. Все такие поползновения опять-же должна пресекать система.
Начинай писать стандарт реализации прав доступа в системе Kolibri.
Хотя полную безопасность может обеспечить лишь наличие своей собственной независимой файловой системы, для которой нет драйвера в других ОС. Разумеется, пока не реализуют в других ОС. Но можно ведь оставить тонкости, которые будут известны лишь разработчикам. И вообще здесь попахивает закрытостью кода драйвера и коммерческим применением.

Mario79, сорри, но я подхватил идею bw, хотя впрочем это не ново...

Mario79
ИМХО стандарты мне еще писать не приходилось. Так как я понял склоняемся к варианту с системными файлами, хорошо, подумаю еще отпишусь.

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

Будет ли новая fs или портированная старая (например чем плоха reiserfs) или останется FAT главное, насколько удобными и безопастным будут методы ее использования. А закрытость как то претит.