Mario79
Для этого нужно чтобы ядро хранило в области своей памяти пути к программам.
Только к запущенным программам и то к программам из системной папки (сервисы, окружение ядра) достаточно флага доступа. Однако для приложений пользующихся системными сервисами придется дополнительно сохранять пути открытых ими файлов. При убиении процесса вся эта инфа должна быть вычищена из памяти.
Т.е. при старте приложения анализируется его путь, выставляется флаг доступа, и если приложение не из системной папки, путь сохраняется.
Есть правда грабли которые нужно учесть - если одна папка вложена в другую а приложение закинуть во внешнюю то оно получает доступ к вложенной(если не запретить запись во вложенною), придется учитывать это для системных папок. Например выложить системные папки в корневой каталог диска, и отслеживать или запретить запуск из него приложений.
На мой взгляд хранимая информация будет не столь уж и велика ну может пара тройка десятков килобайт. Если реализовать ее динамическое распределение не так уж и страшно.
Еще есть смутные мысли про реестр приложений и папок я честно сам не очень соображаю чего думаю, но в общем так:
Вариант 1 (Мне вообщето не нравится) - Регистрируются пути с разным уровнем доступа и регистрируются приложения с флагами доступа. Незарегистрированные пути доступны всем. Зарегистрированные только приложениям с соответствующим кодом доступа. Минус - нет полного визуального контроля за открытием файлов, в путях общего доступа. Однако системные папки защитить можно.
Вариант 2 - Регистрируется приложение с указанием уровня доступа, и, если надо, доступными (рабочими) путями. При запуске приложения система читает запись реестра и по ней создает допуск для приложения. В общем то же что и защита по папкам, но с несколько большими возможностями. Для полного счастья незарегистрированным прогам вообще запретить прямую запись.
Насколько вся эта фишка затормозит систему, ну незнаю, но мне лично хотелось бы иметь систему которая не могла бы чтото творить с моими файлами у меня за спиной, после случайного попадания какой либо вредоносной проги.
SPraid
По мне структуру каталогов надо создавать исходя из того что:
1 - Будут ли в Kolibri относительные пути (сейчас их нет а стандарт '/RD/1/' используется в разных прогах)
2 - Будет ли в Kolibri в дальнейшем многопользовательский режим или нет
3 - Будут ли права доступа и как они будут работать.
4 - Будет ли Kolibri устанавливаться в один раздел с другими OS или нет.(Хотя здесь ответ по моему очевиден.)
А названия, ну можно и так, а /PRG на буковку меньше /PROG.