Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Jun 06, 2020 5:31 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 62 posts ]  Go to page 1 2 3 4 5 Next
Author Message
PostPosted: Wed May 23, 2007 9:36 pm 
Offline
User avatar

Joined: Fri May 18, 2007 11:11 pm
Posts: 125
Я тут решил чуть порассуждать (ногами не бейте) о том какой будет Kolibri в будущем, а точнее о ее файловой структуре. Сейчас ее как таковой нет, в качестве системной папки выступает RAM-диск, защита по правам доступа к файловой системе тоже отсутствует. Сейчас это не критично. Но думаю рано или поздно этот вопрос приобретет значимость.
:roll:
Вот я тут подумал слегка. Используя FAT колибри не сможет реализовать защиту по правам файлов, Однако можно попробовать реализовать защиту по структуре папок.
Скажем доступ для записи в системную папку имеют только приложения из этой папки, они же имеют доступ ко всем остальным папкам.
Далее следует папка общих приложений имеют права на доступ ко всему, кроме системной папки.
Затем следуют папки локальных приложений, их права ограничены доступом на запись только в собственную папку, а для работы с файлами в других папках (кроме системной), возможно использование визуальных системных сервисов (т.е. файл должен быть открыт(в смысле с правом записи) системным сервисом визуально (вручную))
Если делать поддержку многопользовательского режима то у каждого пользователя должна быть своя папка общих приложений, и защита от чтения из других аккаунтов.

Что думаете ? :?:


Top
   
 Post subject:
PostPosted: Wed May 23, 2007 10:39 pm 
Offline
Kernel Developer

Joined: Fri Feb 23, 2007 11:55 pm
Posts: 63
Раз подняли вопрос о файлах... то нада делать каку нибуть структуру каталогов.... мне понравилась структура как Symbian сделана.
1. каталог системы (предлагаю назвать "/sys") - сейчас я сделал "%sys%", но как потом понял - это писать неудобно
2. каталог программ (предлагаю назвать "/prog") -

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


Top
   
 Post subject:
PostPosted: Thu May 24, 2007 7:22 am 
Alver
Quote:
Скажем доступ для записи в системную папку имеют только приложения из этой папки, они же имеют доступ ко всем остальным папкам.
Далее следует папка общих приложений имеют права на доступ ко всему, кроме системной папки.
Затем следуют папки локальных приложений, их права ограничены доступом на запись только в собственную папку, а для работы с файлами в других папках (кроме системной), возможно использование визуальных системных сервисов (т.е. файл должен быть открыт(в смысле с правом записи) системным сервисом визуально (вручную))

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


Top
   
 Post subject:
PostPosted: Thu May 24, 2007 6:25 pm 
Offline
User avatar

Joined: Fri May 18, 2007 11:11 pm
Posts: 125
Mario79

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


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

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

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

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

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

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

SPraid


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


Top
   
 Post subject:
PostPosted: Thu May 24, 2007 7:41 pm 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Тема интересная. Завтра отпишусь. Кстати, никто не в курсе, почему sysbin днем стоял?


Top
   
 Post subject:
PostPosted: Fri May 25, 2007 8:31 am 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Alver, у меня разделение доступа прежде всего основано на структуре файловой системы, а уже потом на использовании атрибутов, которых кстати в конкретной ФС может и не быть. Смысл заключается в том, чтобы в обычном режиме работы в корне держать только вирт. каталоги для отдельно взятого пользователя, которым на этапе монтирования присваиваются атрибуты, вообще никак не связанные с физической структурой файловых систем. А уже на более глубоких уровнях вложенности использовать поддерживаемые физические атрибуты, но трактовать их, если это необходимо, по особому в соответствии с общепринятыми правилами VFS. Доступ к файлам в корневом каталоге загрузочного устройства в обычном режиме не возможен (если его специально не примонтировать), т.к. после инициализации физическая составляющая корня демонтируется и остается лишь вирт. часть.


Top
   
 Post subject:
PostPosted: Fri May 25, 2007 12:27 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Alver
В Колибри уже есть относительные пути (начиная со вчерашнего дня :))


Top
   
 Post subject:
PostPosted: Fri May 25, 2007 4:33 pm 
Offline
User avatar

Joined: Fri May 18, 2007 11:11 pm
Posts: 125
diamond wrote:
В Колибри уже есть относительные пути (начиная со вчерашнего дня)

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

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

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


Top
   
 Post subject:
PostPosted: Fri May 25, 2007 4:54 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
Описывать права доступа вполне можно и в отдельном файле в текущей папке с наследованием дочерними. Файл, для примера, можно назвать ".access" и позволить работать с ним только системе, а для прикладных приложений его вообще можно скрывать. Мне такой вариант кажется наиболее простым и прозрачнын. К тому же он не накладывает ограничений на используемую ФС.

..bw


Top
   
 Post subject:
PostPosted: Fri May 25, 2007 8:21 pm 
Offline
User avatar

Joined: Fri May 18, 2007 11:11 pm
Posts: 125
SPraid
Пардон я не въехал что ты делал доступ к системной папке йз корня - туплю иногда.

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


Top
   
 Post subject:
PostPosted: Fri May 25, 2007 9:29 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
Подобный иерархический анализ будет присутствовать во всех системах. Я думаю что такие глубокие пути пока не ожидаются, да и в будущем они вряд ли будут сильно тормазить систему. Права определяются не при чтении файла, а при открытии, и определяться они должны сверху, ИМХО, т.е. с folx.

..bw


Top
   
 Post subject:
PostPosted: Fri May 25, 2007 9:42 pm 
Offline

Joined: Fri Jan 06, 2006 6:05 am
Posts: 102
ага, как .htaccess на Web-сервере, если файл имеется в папке folx, то права доступа определяет он иначе смотрим каталог выше


Top
   
 Post subject:
PostPosted: Fri May 25, 2007 10:12 pm 
Alver
Если анализировать в обратном порядке как предложил mistifi(ator, то будет работать намного быстрей. Другой вопрос, что приложение может захотеть получить доступ к файлу конфигурации, а если его нет, то создать. Все такие поползновения опять-же должна пресекать система.
Начинай писать стандарт реализации прав доступа в системе Kolibri. :-)
Хотя полную безопасность может обеспечить лишь наличие своей собственной независимой файловой системы, для которой нет драйвера в других ОС. Разумеется, пока не реализуют в других ОС. Но можно ведь оставить тонкости, которые будут известны лишь разработчикам. И вообще здесь попахивает закрытостью кода драйвера и коммерческим применением.


Top
   
 Post subject:
PostPosted: Fri May 25, 2007 11:02 pm 
Offline

Joined: Fri Jan 06, 2006 6:05 am
Posts: 102
Mario79, сорри, но я подхватил идею bw, хотя впрочем это не ново...


Top
   
 Post subject:
PostPosted: Fri May 25, 2007 11:31 pm 
Offline
User avatar

Joined: Fri May 18, 2007 11:11 pm
Posts: 125
Mario79
ИМХО стандарты мне еще писать не приходилось. Так как я понял склоняемся к варианту с системными файлами, хорошо, подумаю еще отпишусь.
Quote:
Хотя полную безопасность может обеспечить лишь наличие своей собственной независимой файловой системы, для которой нет драйвера в других ОС. Разумеется, пока не реализуют в других ОС. Но можно ведь оставить тонкости, которые будут известны лишь разработчикам. И вообще здесь попахивает закрытостью кода драйвера и коммерческим применением.

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 62 posts ]  Go to page 1 2 3 4 5 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited