Page 2 of 5

Posted: Sat May 26, 2007 9:06 am
by Phantom-84
По мне монтаж и демонтаж устройств в папки пользователя в Kolibri будет выглядеть несколько диковато. Тем более что схема корневого каталога уже состоялась. Проще в него добавить виртуальный путь к системной папке (что уже сделано diamondом), и к папке пользователя (папке приложений и т.д.).
А я не говорю, что должны монтироваться устройства! К корню могут монтироваться отдельные каталоги устройства! Причем реальные имена и атрибуты этих каталогов после монтирования вообще никак не будут задействованы. Будут использоваться только вирт. атрибуты и имена, заданные при монтировании. Мне кажется, это похоже на то, что ты предлагал. А сделать это можно путем расширения файловой структуры Колибри. Судя по всему, от того, что ты описал, мой вариант оличается только тем, что у меня нет жесткого закрепления имен вирт. каталогов по назначению, и количество таких каталогов может быть произвольным. Все зависит от настройки.

Posted: Sat May 26, 2007 10:40 am
by Phantom-84
Описывать права доступа вполне можно и в отдельном файле в текущей папке с наследованием дочерними. Файл, для примера, можно назвать ".access" и позволить работать с ним только системе, а для прикладных приложений его вообще можно скрывать. Мне такой вариант кажется наиболее простым и прозрачнын. К тому же он не накладывает ограничений на используемую ФС.
Т.е. приложениям можно и не дергаться в сторону создания файла с именем ".access", а если они успели это сделать раньше, чем система, то в определенных обстоятельствах она может и запороть хранящиеся в нем данные : - ) Наследование доступа можно реализовать и без поддержки системы: на прикладном уровне простым переприсваиванием атрибутов вложенным элементам каталога (конечно, если физическая структура ФС допускает хранение таких атрибутов); на уровне сервера NFS путем организации базы данных для тех элементов, которым объявлялся общий доступ (у меня будет использоваться смешенный вариант - VFS уже поддерживает атрибут net shared, при наличии которого сервер NFS будет использовать дополнительные сведения из собственной базы данных). По поводу естественного наследования дуступа могу сказать только то, что у меня наследование распространяется только на следующий уровень вложенности относительно данного и только на структуру каталога, т.е. в каталоге, доступном по чтению, нельзя изменять набор объектов или их атрибуты, но это не касаеся более глубоких уровней вложенности.

Posted: Sat May 26, 2007 2:51 pm
by Alver
Блин чтото комп стал подглючивать.

Phantom-84
...мой вариант оличается только тем, что у меня нет жесткого закрепления имен вирт. каталогов по назначению, и количество таких каталогов может быть произвольным.
Тут я против, наоборот имена виртуальных каталогов должны быть закреплены жестко, и не допускать никакой путаницы и двусмыслицы.
Т.е. приложениям можно и не дергаться в сторону создания файла с именем ".access", а если они успели это сделать раньше, чем система, то в определенных обстоятельствах она может и запороть хранящиеся в нем данные
Имеется ввиду раньше чем система была установлена? Поскольку иначе система не даст его создать. Однако эти файлы могут быть созданы/удалены соседствующей системой.
Что касается сервера NFS если честно я в этом как то не очень. Понял что используется база данных каталогов и приложений т.е. реестр. Возможно это будет более быстрый способ, но подозреваю что для обработки базы потребуется больше памяти, значит придется сэкономить на количестве элементов.
Что касается наследования, думаю требуется отдельное свойство характеризующее режин наследования для кокретной папки.
Погодя выложу некоторые соображения.

Posted: Sat May 26, 2007 8:20 pm
by Phantom-84
Тут я против, наоборот имена виртуальных каталогов должны быть закреплены жестко, и не допускать никакой путаницы и двусмыслицы.
Для Колибри, возможно, подойдет и этот вариант, но мой более гибкий.
Имеется ввиду раньше чем система была установлена? Поскольку иначе система не даст его создать. Однако эти файлы могут быть созданы/удалены соседствующей системой.
Я вообще против, чтобы подобными "комбинациями" с файлами занималось непосредственно ядро. Пусть это делает драйвер, непосредственно управляющий конкретной ФС, если с другими вариантами возникают проблемы. Кстати, я где-то читал, что полуось для FAT использует атрибут vol, чтобы в корневом каталоге диска прятать файл, содержащий расширенные атрибуты (как удается различать эту запись и собственно метку тома, я не знаю). По идее в отдельно взятом каталоге можно хранить одноименные запись о файле/каталоге и метку тома. Такие записи можно использовать как альтернативу файлам ".access". Опять-таки кстати, но уже вопрос... В FAT в байте атрибутов есть два незадействованных бита. Кто-нибудь их использует? Я слышал, что WinNT использовала один из этих битов, вот только какой? Я юзаю шестой бит (при нумерации с нуля) как executable. Может, лучше для этого задействовать седьмой, чтобы не входить в конфликт с WinNT? А вообще хотелось бы юзать оба, чтобы не изголяться с sys и hid.
Что касается сервера NFS если честно я в этом как то не очень.
Конкретно с NFS я не разбирался, просто при создании VFS пытался учесть возможные перспективы развития.

Posted: Sat May 26, 2007 11:15 pm
by Alver
Phantom-84
Почитал малость доки по FAT32 на wasm.ru, думаю нестандартное использование атрибутов FAT небезопасно, хотя MS вроде бы ее дальше не развивает, но кто знает. А кроме того, работая еще и с windoй или другой осью можно нарваться на какой нибудь хитрый драйвер, сканер или дефрагментатор который 'исправит' наши атрибуты и снесет спрятанные файлы.

Posted: Sun May 27, 2007 12:06 am
by Alver
Попытался представить файловую структуру системы с разделением прав доступа по системным каталогам. Получилось правда несколько раскидано.:wink:

Code: Select all

kolibri - папка контейнер системы
|
|--box - контейнер для паролей и др. конфиденц. информации
|--kernel - ядро и его сервисы
|--drivers - драйверы
|--fonts - шрифты
|--sdll - системные библиотеки
|--admin - программы администратора
|--system - системные программы
|--dll - библиотеки
|--prog - папка программ
|  |
|  |--all - общие программы
|  |--ownerN - программы пользователей и групп
|  ...
|
|--usr - папка конфигураций
|  |
|  |--all - общие конфигурации
|  |--ownerN - конфигурации пользователей и групп
|  ...
|
|--docs - папка документов
|  |
|  |--all - общие документы
|  |--visitor - гостевая папка
|  |--ownerN - документы пользователей и групп
|  ...
|
|--trash - корзина - если нужна
   |
   |--all - общая
   |--visitor - гостевая
   |--ownerN - пользователей
   ...
Немного пояснения: планировалось 4 уровня допуска(точнее еще 5-й гостевой если он нужен)
1: Высший-архиадминистратор - фактически уровень ядра и системных сервисов. box,kernel,drivers,fonts,sdll (в ручную для обновления системы и правки высшего пилотажа)
2: Административный-администратор - уровень системных программ admin,system,dll (установка системных и общих программ).
3: Юзерский - пользователь, группа - уровень приложений и документов общих и пользовательских prog,usr,docs-подпапки all, visitor,owner(только доступные)
4: Общий - все пользователи кроме гостя - уровень общих приложений и документов(включая гостя) - папки all(без записи) visitor
5: Гостевой - гость - самый бесправный - уровень общих приложений и документов только гостя папки visitor

Потом более детально, сейчас интересны мнения.:?:

Posted: Sun May 27, 2007 12:03 pm
by Phantom-84
Потом более детально, сейчас интересны мнения.
Это уже получается не просто вирт. каталоги в корне, а еще и вложенные вирт. каталоги? Если нет, то возникают все те же вопросы с хранением дополнительных атрибутов. Кстати, посторонние для конкретного пользователя каталоги лучше полностью скрыть от него, тогда можно и не делать дополнительный уровень вложенности. Я даже физически предпочитаю разделять данные без дополнительных уровней вложенности:

programs
settings.1
settings.2
...
data.1
data.2
...

Это для варианта, когда всем пользователям доступны одни и те же программы. А после регистрации конкретный пользователь будет видеть только каталоги programs (содержимое объявляется доступным по чтению/исполнению для исполняемых файлов), settings и data (вирт. каталоги для всех пользователей лучше делать одноименными, особенно это касается каталогов с профильными данными программ, т.к. я предпочитаю в глобальных конфиг-файлах приложений хранить одно имя профильного конфиг-файла, которое для каждого пользователя будет указывать на его персональный файл; это кстати позволяет в ряде случаев вообще не использовать глобальные конфиг-файлы для подобных целей, если местоположение профильного конфиг-файла жестко закреплено в самой программе).

Posted: Sun May 27, 2007 2:42 pm
by Alver
Phantom-84
...возникают все те же вопросы с хранением дополнительных атрибутов.
Идея в том чтобы в пределах основной системной архитектуры в конкретные зарезервированные папки складывать файлы с соответствующими им правами доступа. Что касается вложенности, в принципе можно все вывалить в главный каталог в данном случае меня несколько испугала возникающая в этом случае визуальная нелогичность. Впрочем похоже ты прав, проверить единичную вложенность быстрее.
Это уже получается не просто вирт. каталоги в корне, а еще и вложенные вирт. каталоги?
Вообщето расчитывалось на реальные каталоги в системной папке, виртуальными будут: путь к системной папке ну и к папкам данных пользователя с фиксированными для системы именами. Единственно придется отслеживать и определять идентичность виртуального и реального пути к системной папке. (Если данные пользователя вынесены за пределы системной папки тогда и путь к данным пользователя)

Posted: Sun May 27, 2007 2:44 pm
by Alver
Вообще прошу прощения, я вывалил схему без всех необходимых пояснений. Было поздно уже не было времени и глаза устали. Попробую вначале пояснить основы идеи.
Основная идея - файлы в зависимости от своего назначения и атрибутов рассовываются по соответствующим зарезервированным системным папкам, это в принципе позволит избежать двусмысленностей с атрибутами и атрибуты смогут быть определены всего лишь по анализу строки пути(+анализ пути текущей папки). Вложенные в зарезервированные папки подпапки, наследуют свойства родителей до вершины ветки дерева папок. Папки и файлы вне основной системной папки считаются с атрибутами общего доступа (если только не будет реализован механизм хранения атрибутов).
Принцип работы - при загрузке системы происходит залогивание пользователя либо гостя. Под администратора и архиадминистратора отдельной учетки не выдается но пользователь(или гость) может выбрать допуск к правам администратора через системный сервис(со вводом пароля или без по конфигурации) далее переключение на права пользователя/админа или архиадмина ведется опять таки сервисом визуально вручную (нажал кнопочку).
Пользователь может войти только в те ветки системной папки которые, ему дозволяется читать системой Его папки и папки его групп. Чужие учетки недоступны.(Имеется в виду системными программами, допуск общих и пользовательских приложений еще меньше)
Некоторые папки не может читать никто кроме архиадмина и нескольких системных сервисов - 'box' можно назвать их темными папками(хранение паролей и явок)
Далее если в linux и windows любая прога запущенная от лица админа обладает правами админа, то здесь это правило верно лишь для системных программ и программ администратора,остальные проги имеют права доступа в зависимости от ветки системной папки из которой они запущены (из некоторых веток вообще нельзя запустить проги).
Так что я еще забыл? А про группы. Тут еще вертятся в голове мысли. Пожалуй для групп придется создать свои учетки, общую папку и (а надо ли?) папки входящих пользователей - просмотреть могут все члены группы, а изменить только пользователь.
Ну а схему придется поправить.

Posted: Sun May 27, 2007 3:14 pm
by Veliant
Есть еще предложение =) А что если сделать как в Apache в каждой папке валяется скрытый файлик(.htaccess) который содержит об уровне доступа к содержимому этой папки

Posted: Sun May 27, 2007 3:36 pm
by Phantom-84
Идея в том чтобы в пределах основной системной архитектуры в конкретные зарезервированные папки складывать файлы с соответствующими им правами доступа.
Идея понятна. Я предпочитаю использовать вирт. атрибуты.
Вообщето расчитывалось на реальные каталоги в системной папке, виртуальными будут: путь к системной папке...
Ну что ж, это вполне нормально, но тогда проще все системные данные и программы разместить внутри одного каталога, а у тебя kernel, drivers и т.п. вместе с prog!
Так что я еще забыл? А про группы. Тут еще вертятся в голове мысли. Пожалуй для групп придется создать свои учетки, общую папку и (а надо ли?) папки входящих пользователей - просмотреть могут все члены группы, а изменить только пользователь.
У меня разделение по группам основано на все том же произвольном конструировании корня для отдельных пользователей, правда, если общедоступные каталоги можно прописать в общем конфигурационном системном файле, то каталоги отдельной группы нужно прописывать для каждого члена группы.

Posted: Sun May 27, 2007 3:41 pm
by Phantom-84
Veliant, этот вариант уже упоминался.

Posted: Sun May 27, 2007 3:52 pm
by Alver
Veliant
Есть еще предложение =) А что если сделать как в Apache в каждой папке валяется скрытый файлик(.htaccess) который содержит об уровне доступа к содержимому этой папки
Фактически тоже предлагал bw. Кстати если есть ссылочка на документацию по этому файлу на русском киньте плиз.
Если попробовать сравнить оба варианта: в первом фактически права доступа определяются сравнением строки запускаемого или открываемого файла с парой десятков шаблонов строк системных папок, на совпадение начального участка пути, по моему это быстрее. Но отсутствует возможность установки атрибутов за пределами контейнера системной папки. Во втором таких ограничений нет но придется тратить время на чтение дополнительного файла и его дешифрацию.
Возможно имеет смысл обьединить оба этих варианта - первый для системной папки, где файл '.htaccess' будет игнорироваться за ненадобностью а второй за ее пределами? :?:
Нужно посмотреть подойдут ли права описываемые в файлах Apachа для наших нужд, тогда и формат можно готовый использовать.

Posted: Sun May 27, 2007 4:03 pm
by Phantom-84
Принцип работы - при загрузке системы происходит залогивание пользователя либо гостя. Под администратора и архиадминистратора отдельной учетки не выдается но пользователь(или гость) может выбрать допуск к правам администратора через системный сервис(со вводом пароля или без по конфигурации) далее переключение на права пользователя/админа или архиадмина ведется опять таки сервисом визуально вручную (нажал кнопочку).
Это было бы круто :)
Возможно, я сделаю нечто подобное, если решусь на усложнение своей системы в сторону возможности быстрой смены пользователя. Пока что для серьезной настройки системы необходима хотябы одна соответствующая регистрационная запись. Если таких записей нет, то систему можно подредактировать только "со стороны" : - ) Хотя хотелось бы заметить, что и полную перезагрузку выполнять не нужно, необходимо только завершить текущий сеанс, при этом все что было загружено на общем этапе инициализации, перезагружать не надо.

Posted: Sun May 27, 2007 4:18 pm
by Alver
Phantom-84 wrote:Ну что ж, это вполне нормально, но тогда проще все системные данные и программы разместить внутри одного каталога, а у тебя kernel, drivers и т.п. вместе с prog!.
Замечание принято. Дело в том что поначалу я и хотел сделать как ты говоришь но хотел слепить структуру которая подошла бы и под предложение bw . А раскинуть 'prog', 'usr',... всетаки не решился, совсем структура теряется. Теперь думаю что в этом нет нужды (покрайней мере для системных папок). Схему переделаю.