Зарегистрирован: 18.05.2007 Сообщения: 89 Откуда: Смоленская область
Добавлено: Wed May 23, 2007 6:36 pm Заголовок сообщения: О правах и файлах
Я тут решил чуть порассуждать (ногами не бейте) о том какой будет Kolibri в будущем, а точнее о ее файловой структуре. Сейчас ее как таковой нет, в качестве системной папки выступает RAM-диск, защита по правам доступа к файловой системе тоже отсутствует. Сейчас это не критично. Но думаю рано или поздно этот вопрос приобретет значимость.
Вот я тут подумал слегка. Используя FAT колибри не сможет реализовать защиту по правам файлов, Однако можно попробовать реализовать защиту по структуре папок.
Скажем доступ для записи в системную папку имеют только приложения из этой папки, они же имеют доступ ко всем остальным папкам.
Далее следует папка общих приложений имеют права на доступ ко всему, кроме системной папки.
Затем следуют папки локальных приложений, их права ограничены доступом на запись только в собственную папку, а для работы с файлами в других папках (кроме системной), возможно использование визуальных системных сервисов (т.е. файл должен быть открыт(в смысле с правом записи) системным сервисом визуально (вручную))
Если делать поддержку многопользовательского режима то у каждого пользователя должна быть своя папка общих приложений, и защита от чтения из других аккаунтов.
Добавлено: Wed May 23, 2007 7:39 pm Заголовок сообщения:
Раз подняли вопрос о файлах... то нада делать каку нибуть структуру каталогов.... мне понравилась структура как Symbian сделана.
1. каталог системы (предлагаю назвать "/sys") - сейчас я сделал "%sys%", но как потом понял - это писать неудобно
2. каталог программ (предлагаю назвать "/prog") -
а файле конфигурации можно как объединить эти каталоги (на самом деле это один каталолог), так и сделать их на разных физических дисках....
Зарегистрирован: 19.05.2005 Сообщения: 1966 Откуда: РФ, г. Челябинск
Добавлено: Thu May 24, 2007 4:22 am Заголовок сообщения:
Alver
Цитата:
Скажем доступ для записи в системную папку имеют только приложения из этой папки, они же имеют доступ ко всем остальным папкам.
Далее следует папка общих приложений имеют права на доступ ко всему, кроме системной папки.
Затем следуют папки локальных приложений, их права ограничены доступом на запись только в собственную папку, а для работы с файлами в других папках (кроме системной), возможно использование визуальных системных сервисов (т.е. файл должен быть открыт(в смысле с правом записи) системным сервисом визуально (вручную))
Для этого нужно чтобы ядро хранило в области своей памяти пути к программам. В текущем ядре путь выдается приложению при старте, если приложению не нужен путь, он вообще не сохраняется. В текущей реализации путь легко подменить, но экономиться память, так как не всем приложениям нужен путь.
Зарегистрирован: 18.05.2007 Сообщения: 89 Откуда: Смоленская область
Добавлено: Thu May 24, 2007 3:25 pm Заголовок сообщения:
Mario79
Цитата:
Для этого нужно чтобы ядро хранило в области своей памяти пути к программам.
Только к запущенным программам и то к программам из системной папки (сервисы, окружение ядра) достаточно флага доступа. Однако для приложений пользующихся системными сервисами придется дополнительно сохранять пути открытых ими файлов. При убиении процесса вся эта инфа должна быть вычищена из памяти.
Т.е. при старте приложения анализируется его путь, выставляется флаг доступа, и если приложение не из системной папки, путь сохраняется.
Есть правда грабли которые нужно учесть - если одна папка вложена в другую а приложение закинуть во внешнюю то оно получает доступ к вложенной(если не запретить запись во вложенною), придется учитывать это для системных папок. Например выложить системные папки в корневой каталог диска, и отслеживать или запретить запуск из него приложений.
На мой взгляд хранимая информация будет не столь уж и велика ну может пара тройка десятков килобайт. Если реализовать ее динамическое распределение не так уж и страшно.
Еще есть смутные мысли про реестр приложений и папок я честно сам не очень соображаю чего думаю, но в общем так:
Вариант 1 (Мне вообщето не нравится) - Регистрируются пути с разным уровнем доступа и регистрируются приложения с флагами доступа. Незарегистрированные пути доступны всем. Зарегистрированные только приложениям с соответствующим кодом доступа. Минус - нет полного визуального контроля за открытием файлов, в путях общего доступа. Однако системные папки защитить можно.
Вариант 2 - Регистрируется приложение с указанием уровня доступа, и, если надо, доступными (рабочими) путями. При запуске приложения система читает запись реестра и по ней создает допуск для приложения. В общем то же что и защита по папкам, но с несколько большими возможностями. Для полного счастья незарегистрированным прогам вообще запретить прямую запись.
Насколько вся эта фишка затормозит систему, ну незнаю, но мне лично хотелось бы иметь систему которая не могла бы чтото творить с моими файлами у меня за спиной, после случайного попадания какой либо вредоносной проги.
SPraid
По мне структуру каталогов надо создавать исходя из того что:
1 - Будут ли в Kolibri относительные пути (сейчас их нет а стандарт '/RD/1/' используется в разных прогах)
2 - Будет ли в Kolibri в дальнейшем многопользовательский режим или нет
3 - Будут ли права доступа и как они будут работать.
4 - Будет ли Kolibri устанавливаться в один раздел с другими OS или нет.(Хотя здесь ответ по моему очевиден.)
А названия, ну можно и так, а /PRG на буковку меньше /PROG.
Добавлено: Fri May 25, 2007 5:31 am Заголовок сообщения:
Alver, у меня разделение доступа прежде всего основано на структуре файловой системы, а уже потом на использовании атрибутов, которых кстати в конкретной ФС может и не быть. Смысл заключается в том, чтобы в обычном режиме работы в корне держать только вирт. каталоги для отдельно взятого пользователя, которым на этапе монтирования присваиваются атрибуты, вообще никак не связанные с физической структурой файловых систем. А уже на более глубоких уровнях вложенности использовать поддерживаемые физические атрибуты, но трактовать их, если это необходимо, по особому в соответствии с общепринятыми правилами VFS. Доступ к файлам в корневом каталоге загрузочного устройства в обычном режиме не возможен (если его специально не примонтировать), т.к. после инициализации физическая составляющая корня демонтируется и остается лишь вирт. часть.
Зарегистрирован: 18.05.2007 Сообщения: 89 Откуда: Смоленская область
Добавлено: Fri May 25, 2007 1:33 pm Заголовок сообщения:
diamond писал(а):
В Колибри уже есть относительные пути (начиная со вчерашнего дня)
Извини прошляпил!
Phantom-84
Цитата:
Доступ к файлам в корневом каталоге загрузочного устройства в обычном режиме не возможен (если его специально не примонтировать)
По мне монтаж и демонтаж устройств в папки пользователя в Kolibri будет выглядеть несколько диковато. Тем более что схема корневого каталога уже состоялась. Проще в него добавить виртуальный путь к системной папке (что уже сделано diamondом), и к папке пользователя (папке приложений и т.д.).
Добавлено: Fri May 25, 2007 1:54 pm Заголовок сообщения:
Описывать права доступа вполне можно и в отдельном файле в текущей папке с наследованием дочерними. Файл, для примера, можно назвать ".access" и позволить работать с ним только системе, а для прикладных приложений его вообще можно скрывать. Мне такой вариант кажется наиболее простым и прозрачнын. К тому же он не накладывает ограничений на используемую ФС.
Зарегистрирован: 18.05.2007 Сообщения: 89 Откуда: Смоленская область
Добавлено: Fri May 25, 2007 5:21 pm Заголовок сообщения:
SPraid
Пардон я не въехал что ты делал доступ к системной папке йз корня - туплю иногда.
bw
В принципе действительно прозрачно и работоспособно но сомнения насчет наследования. Скажем прграмма хочет записать файл '/hd0/1/fol1/fol2/fol3/.../folx/text.txt' и система вначале ищет файл '.access' в 'fol1', читает его, если запись разрешена, ищет файл в 'fol2', опять читает и так пока не дойдет до 'folx'. Хотя если вложенность файлов не велика можно и так, но при большом количестве файлов и сильной вложенности может и притормаживать.
хотя мне кажется проанализировать путь легче чем вычитывать файлы в каждом каталоге, хотя может я и ошибаюсь.
Добавлено: Fri May 25, 2007 6:29 pm Заголовок сообщения:
Подобный иерархический анализ будет присутствовать во всех системах. Я думаю что такие глубокие пути пока не ожидаются, да и в будущем они вряд ли будут сильно тормазить систему. Права определяются не при чтении файла, а при открытии, и определяться они должны сверху, ИМХО, т.е. с folx.
Зарегистрирован: 19.05.2005 Сообщения: 1966 Откуда: РФ, г. Челябинск
Добавлено: Fri May 25, 2007 7:12 pm Заголовок сообщения:
Alver
Если анализировать в обратном порядке как предложил mistifi(ator, то будет работать намного быстрей. Другой вопрос, что приложение может захотеть получить доступ к файлу конфигурации, а если его нет, то создать. Все такие поползновения опять-же должна пресекать система.
Начинай писать стандарт реализации прав доступа в системе Kolibri.
Хотя полную безопасность может обеспечить лишь наличие своей собственной независимой файловой системы, для которой нет драйвера в других ОС. Разумеется, пока не реализуют в других ОС. Но можно ведь оставить тонкости, которые будут известны лишь разработчикам. И вообще здесь попахивает закрытостью кода драйвера и коммерческим применением.
Зарегистрирован: 18.05.2007 Сообщения: 89 Откуда: Смоленская область
Добавлено: Fri May 25, 2007 8:31 pm Заголовок сообщения:
Mario79
ИМХО стандарты мне еще писать не приходилось. Так как я понял склоняемся к варианту с системными файлами, хорошо, подумаю еще отпишусь.
Цитата:
Хотя полную безопасность может обеспечить лишь наличие своей собственной независимой файловой системы, для которой нет драйвера в других ОС. Разумеется, пока не реализуют в других ОС. Но можно ведь оставить тонкости, которые будут известны лишь разработчикам. И вообще здесь попахивает закрытостью кода драйвера и коммерческим применением.
Будет ли новая fs или портированная старая (например чем плоха reiserfs) или останется FAT главное, насколько удобными и безопастным будут методы ее использования. А закрытость как то претит.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
)