Board.KolibriOS.org

Phantom-84

Ты хочешь структурно решить задачу, с которой не всегда справляются опытные админы?

Ну хотябы затруднить вражебные действия.

Если ты спрашиваешь про GFT, то там хранятся сведения только об открытых файлах, присоединенных и "активных" каталогах.

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

У меня данные можно во-первых полностью скрыть от рядового пользователя системы (не только структурно, т.е. вообще не прилинковывать определенные физические каталоги, но и с помощью спец. атрибута), во-вторых можно сделать так, чтобы данные для рядового пользователя были доступны только по чтению (атрибут local shared).

Согласен что можно часть системы скрыть от пользователей обычными атрибутами FAT. Но этот вариант определяет только отношения пользователь-система, и не определяет программа-пользователь, и еще менее определяет пользователь-пользователь, для этих отношений структурный вариант просто необходим. А имея структурный вариант стоит ли тянуть еще и атрибутный. Зарожденное тобой зерно сомнения во мне все более прорастает в сторону присутствия системных файлов конфигурации доступа программ и упрощения схемы файловой структуры на несколько более близкую к винде.

Чтото в этом духе.

Mario79

Блин да вы что парни! Даже мелкософт сам отказался от реестра, раскидав настройки по множеству файлов.

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

Я рискну сказать, что реализация относительно банальных "юниховых" прав aka (read|write|exec) <-> (owner|group|other) для файлов и директорий(читай: в файловой системе, FATxx....не стоит брать в расчёт, несмотря на поддерживаемость только её по-хорошему) и соответствующие проверки в коде основных файловых операций(create, close, read, write) дадут довольно удобную изменяемую и настраиваемую систему, которую можно положить за базу =)

Хранится это должно в памяти процессу не доступной, создаваться или читаться из конфигураций при запуске процесса...

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

Согласен что можно часть системы скрыть от пользователей обычными атрибутами FAT. Но этот вариант определяет только отношения пользователь-система, и не определяет программа-пользователь, и еще менее определяет пользователь-пользователь, для этих отношений структурный вариант просто необходим. А имея структурный вариант стоит ли тянуть еще и атрибутный.

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

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

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

smb-, в Unix-подобных системах все равно слишком много флагов атрибутов, чтобы нормально разделять данные в FAT. А структурный подход позволяет управлять доступом даже в FAT (я, например, еще не научился упралять ФС, отличными от FAT, но благодаря структурному подходу могу разделять данные между отдельными пользователями на FAT-разделах).

smb-
Несколько раз перечитав пост, я так понял что ты ратуешь за другую fs. Думаю не скоро еще будет.

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

Таким образом легко определяются права отношений пользователь <=> система и пользователь <=> пользователь. Т.е. фактически уровень защиты unix,linux и т.п. Если будет сочтено что этого уровня достаточно...
У меня была идея сделать еще более высокий уровень контроля с определением отношений прав программа <=> пользователь. Права приложения складываются из прав пользователя и прав приложения. Права пользователя с его путями доступа, естественно хранятся в системе на протяжении сеанса, и хранить их еще и для приложений лишнее. Для каждого приложения требуется хранить лишь то что требуется системе для обеспечения прав доступа приложения внутри прав пользователя. Если приложению не требуется запись или еще чтото специфическое то и хранить нечего.

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

Фактически поиск конфигурационной записи о приложении, выставление переменных(если они требуются), и собственно запуск.

Alver
Правильнее сказать, что я ратую за механизм прав, поддерживающийся во многих современных и даже не очень файловых системах, но не поддерживающийся в FATxx, и механизм их проверок. Реализация общего механизма проверок прав доступа при open|close|read|write - нужна, думаю, бесспорно. Это раз.
Далее, можно сделать её, и для FAT прописать получение соответствующих атрибутов из конфигурационных файлов, а не из inode-ов директорий, как в остальных FS(-> NTFS).
Ратую за другую ФС - в принципе да, банально с точки зрения плохой организации FAT, но открыто не ратую - так надо быть готовым ответить за это, написав драйвер другой ФС, чего мне как-то не хочется и не можется наверное =)

У меня была идея сделать еще более высокий уровень контроля с определением отношений прав программа <=> пользователь. Права приложения складываются из прав пользователя и прав приложения.

Можно разрешить запускать исполняемые файлы только из ветки programs, но мне кажется, это станет существенным ограничением. Со сменных носителей уже ничего не запустить. Кстати, можно попробовать и через атрибуты. Например, чтобы флаг executable, установленный у каталога, разрешал запускать из него файлы и был недоступен для модификации рядовому пользователю. Идея вроде бы ничего. Надо бы ее тщательно проанализировать : - )

Phantom-84

Можно разрешить запускать исполняемые файлы только из ветки programs

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

Не. Не пойдет, просто все проги перекочуют в эту ветку и ничего не изменится.

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

Смысл не в ограничении запуска, а в контроле полномочий программы, фактически файловый файрвол, кстати сюда же и сетевой можно на одном дыхании вставить.

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

OFFTOP
"Я злой и страшный серый волк. Я в поросятах знаю толк!" (с) "Джентльмены удачи"
Я не понимаю людей, которые пишут на заборах слово из трех букв.
Я не понимаю, зачем критиковать готовый стандарт виртуальной системы, когда обсуждение его реализации было открытым, и каждый мог принять участие в обсуждении.
Я много чего не понимаю, но вот это я тоже не понимаю:
http://blog.mikedld.com/

"About rights and files" © Alver
OK, I was finally sent down from the university since haven't passed Math exam in time. This is not something I'm gonna cry to death, but this is sad. Remind me not to be such an idiot next time
There's a topic titled like the post you're reading now on Russian Kolibri board, and despite it's in "Offtopic" forum

и далее по тексту.
Неужели тяжело здесь выразить свое мнение? Все разбанены, за выражение мнения без личных оскорблений никто никогда никого не лупит.
Разумные ведь люди (или не разумные?).
Почему так?
Почему, вместо того чтобы нормально обсудить, людям приятней плюнуть в спину и обозвать человека нехорошим словом в его отсутствие?
Наверное, я все-таки полный дурак...
:-/
/OFFTOP

Mario79
"Готовый стандарт" - это пожалуй слишком громко, скажем так - предложения для будущей возможной реализации.
По поводу блога - по английски я с трудом, но основную мысль вродебы ухватил. То что kolibri однопользовательская система мне безусловно известно и я вовсе не считаю что все сразу кинутся переписывать ее на многоюзерский вариант.
Но я считаю что рано или поздно вопрос многоюзерности придется решать. А хотелось бы чтобы система была более защищенной чем другие.
Я изначально открыл тему на обсуждение в офтопе, поскольку без подтверждения кодом, это пока офтоп и есть. Когда будет стадия написания кода, это вопрос. Я пока слабоват в программировании и разбираться с кодами мне еще долго. Буду вникать постепенно, но это как время и обстоятельства. Если метры колибри решаться на реализацию будет отлично, если нет думаю со временем и у меня руки дойдут. В любом случае первоначально потребуется реализация именно сервисов работы с файловой системой, доработки десктопа, а права и многопользовательность это конечный шаг.
Останутся ли идеи, возникшие в ходе обсуждения темы офтопом или перейдут в новое качество покажет будущее. Но если они всеже будут кому-либо полезны значит тема была открыта не зря.