О правах и файлах

No comments
  • Code: Select all

    ***********************************************
    Kolibri(sys)
    |
    ==========ядро, библиотеки и пр.
    system--без изменений
    ==========
    |
    ==========данные, конфиги и пр.
    users
     |
      all--bin
         --conf
         --data
         --trash
         --desktop
     |
      user1--***
    ==========
    |
    ==========документы пользователей
    home
     |
      all-*
     |
      user1-*
    ==========
    
    ********************************************
    
    не спалось ночью... решил немного поразмышлять, тема интересная. )
  • AqwAS
    Не спорю выглядит логичнеее и красивее, но есть тут одно соображение которое стоит обдумать а затем решить.

    Дело в том что права этих папок я рассчитывал определять анализом строки пути. Алгоритм может быть двух типов:
    Первый жестко привязан к структуре: вначале проверить содержит ли строка пути вход в главную системную папку ('kolibry'), затем проверка подпапок 'syst', 'conf', 'prog'..., затем в зависимости от результата идет ветвление на проверку подпапок. И в результате выдаются права.
    Второй - проверяются на присутствие цельные шаблоны зарезервированных строк пути, и при положительном результате выдаются права.
    Так вот для первого варианта выгоднее иметь в проверке изменяемые имена в конце списка а не в середине. У меня
    этому правилу не удовлетворяют подпапки групп но тут я не знаю стоит ли оптимизировать таким способом к ним доступ.
    Да еще вот возникла идея - Если сократить имена фиксированных системных папок до трех символов, то вместе со слэшем имя как раз залезет в регистр. Но если для реализации будет предпочтен второй вариант... Впрочем в любом случае чем меньше длина строки тем быстрее сравнение.
  • Отредактировано.

    Code: Select all

    ________________________________|__Read__|_Write_|_Execute_|
    kolibri
    |
    |--system
    |  |
    |  |--data                         Adm     Adm     Not 
    |  |
    |  |--box                          Sys     Sys     Not
    |  |
    |  |--kernel                       All     Sys     All
    |  |
    |  |--sdll [system dll]            All     Sys     Sys
    |  |
    |  |--dll                          All     Adm     Sys
    |  |
    |  |--admin                        Adm     Adm     Adm
    |  |
    |  |--programs [system programs]   All     Adm     All
    |
    |--users    [users locals]
    |  |
    |  |--all
    |  |   |
    |  |   |--programs                 All     Adm     All
    |  |   |
    |  |   |--config                   All     Adm     Not
    |  |   |
    |  |   |--box                      Sys     Sys     Sys
    |  |   |
    |  |   |--data                     All     All     Not
    |  |   |
    |  |   |--docs                     Vis     All     All
    |  |   |
    |  |   |--dll                      All     Adm     Sys
    |  |
    |  |--visitor
    |  |  |
    |  |  |--config                    Vis     Adm     Not
    |  |  |
    |  |  |--box                       Sys     Sys     Sys
    |  |  |
    |  |  |--data                      Vis     Vis     Not
    |  |  |
    |  |  |--docs                      Vis     Vis     All
    |  |
    |  |--uaa
    |  |  ... [Названия папок соответствуют именам пользователей]
    |  |--uPP
    |     |
    |     |--programs                  Usr     Usr     Usr
    |     |
    |     |--config                    Usr     Usr     Not
    |     |
    |     |--box                       Sys     Sys     Not
    |     |
    |     |--data                      Usr     Usr     Not
    |     |
    |     |--docs                      Usr     Usr     Usr
    |     |
    |     |--dll                       Usr     Usr     Sys
    |
    |--groups
    |  |
    |  |--gaa
    |  |  ... [Названия папок соответствуют именам групп]
    |  |--gPP
    |     |
    |     |--programs                 GrpUsr   Grp     GrpUsr
    |     |
    |     |--config                   GrpUsr   Grp     Not
    |     |
    |     |--box                       Sys     Sys     Not
    |     |
    |     |--data                     GrpUsr   Grp     Not
    |     |
    |     |--docs                     GrpUsr   GrpUsr  Not
    |     |
    |     |--dll                      GrpUsr   Grp     Sys
    |
    |--trash                           Sys     Sys     Not
    
    
    Небольшая справка. Теперь корзина одна для всех и обрабатывается системным приложением, все равно для нее надо хранить записи откуда пришел файл (можно там же и права хранить).
    Папки пользователей и групп будут называться именами соответствующих пользователей и групп.

    Каждой системной папке структуры присваиваются фиксированные права доступа.
    Их предполагатся 3 - чтение, запись, исполнение, каждое определяется 2 байтами.
    Младьший описывает тип доступа, старший принадлежность.
    Примерно так:

    Code: Select all

    -------------------------------------------------------------------------------------------
    мл.байт|Обозначение| Описание                              |      Старший байт
    -------|-----------|---------------------------------------|-------------------------------
    0      |  Vis      |Гость + все                            |  - (без разницы)
    1      |  All      |Все пользователи (кроме гостя)         |  -
    2      |  GrpUsr   |Все пользователи группы                |  Номер группы [1..255]
    3      |  Usr      |Конкретный пользователь                |  Номер пользователя [1..255]
    4      |  Grp      |Пользователь группы, имеющий           |  Номер группы [1..255]
           |           | в ней административные права          |
    ------------------------------------------------------------
    5-7    |        Не используется                            |
    8-63   |        Зарезервировано для программ               |
    64-127 |        Зарезервировано для системных программ     |
    ------------------------------------------------------------------------------------------
    128    |  Adm      | Администратор                         | 0
    ------------------------------------------------------------------------------------------
    129-191|        Зарезервировано для сервисов ядра          |
    ------------------------------------------------------------------------------------------
    192    |  Sys      | Архиадминистратор                     | 0
    ------------------------------------------------------------------------------------------
    193-254|        Зарезервировано для сервисов ядра          |
    ------------------------------------------------------------------------------------------
    255    |  Not      |  Никто. Запрещено для всех            | -
    ------------------------------------------------------------------------------------------
    


    Еще одно, пути которые не доходят до системного края ветки, (типа: '.../kolibri/file.xxx', '.../users/all/' - считаются с правами Read-Vis, Write-Sys(для users, и group веток можно-Adm), Execute-Not но не распостраняются на вложенные папки.
    Last edited by Alver on Tue May 29, 2007 2:06 pm, edited 3 times in total.
  • а есть ли смысл разбрасывать dll на каждого пользователя... т.е. по сути к одной библиотеке могут обращаться программы не зависимо от прав пользователя. Почему-бы не ограничится одной папкой?
  • Да еще вот возникла идея - Если сократить имена фиксированных системных папок до трех символов, то вместе со слэшем имя как раз залезет в регистр.
    Не согласен. Во-первых, эти имена будут плохо понятны новым пользователям системы. Во-вторых, я надеюсь, со временем Колибри будет работать с двухбайтовой кодировкой. Зы, у меня таких проблем нет вообще. Я могу одинаково легко составить и структуру каталогов Linux, и структуру каталогов Windows : - )
  • А если вообще имена убать - можно слэш в AL уместить. Минимализм - это хорошо, но в разумных пределах. Как думаешь, обычному пользователю будет очень интересно, что имя папки умещается в регистр? Имена должны быть self-explanatory, а не "slb" и "spr". Будет время - посмотри на структуру каталогов в MacOS: "Applications", "Developer", "Library", "Network", "System", "User Guides And Information", "Users", "Volumes", ".Trashes" и так далее, и так далее, и так далее. И не нужно ломать голову и думать, что это за "slb" такое.
  • Не говоря уже о самой известном в мире папке "Program files" во всем известной Винде...
  • Хорошо, принято, пост отредактировал - ограничения убраны.
    AqwAS wrote:а есть ли смысл разбрасывать dll на каждого пользователя... т.е. по сути к одной библиотеке могут обращаться программы не зависимо от прав пользователя. Почему-бы не ограничится одной папкой?
    Лишние папки можно и не использовать, а вообще предполагается что пользователю может взбрендить установить ряд программ только для себя с библиотеками тоже только для себя, также для группы.
  • О правах программ.
    Доступы к файловой системе на уровне пользователей/групп защищают от убоя системы и любопытных взглядов но не защищают от действий вредоносных программ внутри аккаунта пользователя.
    Я предлагаю поместить программы пользователей/групп в 'бутылки' т.е. ограничить их прямой доступ к файловой системе на запись несколькими доступными путями. Здесь правда уже потребуются системные переменные, имеющие свое значение для каждой запущенной программы.
    Программы в папке '.../system/programs/' в таком ограничении доступа не нуждаются (их ограничат лишь права запустившего пользователя).
    Конкретнее возможно использование разделения данных программы как в linux. В папках пользователей и групп имеются подпапки 'programs', 'configs', 'data'. Значит мыслю так, каждая программа в общем случае имеет:
    1-Точку старта - '/start/' (эти названия только для пояснения)
    2-Папку основных данных - '/data/'
    3-Папку локальных данных (т.е. для пользователя) - '/ldata/'
    4-Папку основной конфигурации -'/conf/'
    5-Папку локальной конфигурации - '/lconf/'
    По адресам переменных данных и конфигурации приложение может писать напрямую.
    Лучше наверно чтобы приложение запрашивало создание нужных ей переменных, в начале запуска,
    с тем чтобы проги не делающие лишних записей не захламляли своими переменными память системы.
    А ко всем остальным каталогам обращение (на запись) будет через визуальные системные сервисы. (Если приложение пытается чтото записать в каталог не через системные переменные, но допустимый по правам пользователя, должно возникнуть исключение вызывающее диалог от системы на подтверждение действия приложения).
    Если приложение запускается не из системной папки, то оно не получает папки данных и конфигураций, точнее получает некий пустой путь с запретом чтения, записи, и код ошибки. Поэтому приложения должны
    будут это учитывать.
    Старые приложения будут либо работать в системной папке, либо требовать подтверждения записи.
  • Доступы к файловой системе на уровне пользователей/групп защищают от убоя системы и любопытных взглядов но не защищают от действий вредоносных программ внутри аккаунта пользователя.
    Ну ты решил прям все защитить, не получится ли так, что даже невредоносные программы будут ограничены в своих действиях? Я предпочитаю для пользователя в режиме настройки (администратора) составлять набор доступных программ и защищать их по записи. Вирусы могут гулять среди самостоятельно установленных пользователем программ и заражать только подобные программы!
    Я предлагаю поместить программы пользователей/групп в 'бутылки' т.е. ограничить их прямой доступ к файловой системе на запись несколькими доступными путями.
    Работа с файловой системой сразу несколькими доступными путями без какой-либо синхронизации - это проблема плохо сколоченной системы! У меня все в конечном итоге проходит через GFT (Global File Table), и прикрепленные (смонтированные) каталоги, и обычные каталоги, и естественно файлы! Это узкое место файловой системы в хорошем смысле этого слова. Лишь после прохождения контроля в GFT идет распределение запросов между драйверами конкретных ФС.
  • 1-Точку старта - '/start/' (эти названия только для пояснения)
    2-Папку основных данных - '/data/'
    3-Папку локальных данных (т.е. для пользователя) - '/ldata/'
    4-Папку основной конфигурации -'/conf/'
    5-Папку локальной конфигурации - '/lconf/'
    Для точки старта предпочитаю использовать текущий каталог, унаследованный от процесса, запустившего данный, плюс должна иметься возможность получить имя каталога, из которого было запущено приложение.

    Основные данные самой программы (не пользователя) и основную конфигурацию можно хранить "ближе" к исполняемым файлам, примерно так, как это реализовано в Windows.
  • Работа с файловой системой сразу несколькими доступными путями без какой-либо синхронизации - это проблема плохо сколоченной системы!
    Я коряво выразился, не работа с файловой системой несколькими путями, а напрямую для пользовательских приложений на запись доступны только несколько путей, начинающихся с сопоставленных приложению системных переменных.
    У меня все в конечном итоге проходит через GFT (Global File Table), и прикрепленные (смонтированные) каталоги, и обычные каталоги, и естественно файлы! Это узкое место файловой системы в хорошем смысле этого слова. Лишь после прохождения контроля в GFT идет распределение запросов между драйверами конкретных ФС.
    Поясни пожалуйста, в своей таблице ты сохраняешь данные на абсолютно все папки и файлы файловой системы или только на специально зарегистрированные. Если на все то при загрузке могут быть тормоза при большом количесве файлов.
    Вирусы могут гулять среди самостоятельно установленных пользователем программ и заражать только подобные программы!
    На вирусе не написано что он вирус, его может и администратор поставить. И тезис: фиг с ними
    с документами главное система цела мне почемуто не нравится.
    Основные данные самой программы (не пользователя) и основную конфигурацию можно хранить "ближе" к исполняемым файлам, примерно так, как это реализовано в Windows.
    Подумать надо.
    Я предпочитаю для пользователя в режиме настройки (администратора) составлять набор доступных программ...
    Да, в принципе наличие реестра программ может упростить дело, если только не создавать виндовых граблей.
    ...и защищать их по записи.
    Мне бы хотелось защитить по записи все программы плюс документы, или хоть уменьшить риск убоя до минимума.
  • Блин да вы что парни! Даже мелкософт сам отказался от реестра, раскидав настройки по множеству файлов.
  • Поясни пожалуйста, в своей таблице ты сохраняешь данные на абсолютно все папки и файлы файловой системы или только на специально зарегистрированные. Если на все то при загрузке могут быть тормоза при большом количесве файлов.
    Если ты спрашиваешь про GFT, то там хранятся сведения только об открытых файлах, присоединенных и "активных" каталогах. Но есть отдельно таблица смонтированных каталогов (тот самый вирт. корень). Если к файловой системе идет запрос, затрагивающий корень, VFS сначала проверяет факт обращения по одной из этих вирт. ветвей, а затем, если такого вхождения не обнаружено, транслирует запрос корневой ФС, ну или заглушке, если корневая ФС на момент запроса уже демонтирована (Пояснение: у меня поддерживаются два режима работы - обычный и настроичный; при инициализации системы прежде всего монтируется корневая ФС для чтения, а затем в зависимости от режима работа она либо демонтируется, либо перемонтируется для чтения-записи).
    На вирусе не написано что он вирус, его может и администратор поставить. И тезис: фиг с ними
    с документами главное система цела мне почемуто не нравится.
    Ты хочешь структурно решить задачу, с которой не всегда справляются опытные админы? Сомневаюсь, что у тебя получится...
    Да, в принципе наличие реестра программ может упростить дело, если только не создавать виндовых граблей.
    Да, я не про реестр! Не хотел вдаваться в подробности того, о чем говорил. Думал, итак понятно. У меня данные можно во-первых полностью скрыть от рядового пользователя системы (не только структурно, т.е. вообще не прилинковывать определенные физические каталоги, но и с помощью спец. атрибута), во-вторых можно сделать так, чтобы данные для рядового пользователя были доступны только по чтению (атрибут local shared). Программы и общедоступные данные я делаю доступными только для чтения конкретному пользователю. Вот типичная структура, которую я прописываю для отдельного пользователя:

    system (атрибут special, в FAT транслируется в system + hidden с накладкой, что не очень существенно, т.к. после установки этого атрибута в вирт. корне нет особой необходимости устанавливать его для вложенных объектов) - если нужна; системные данные в обычном режиме; пользовательским программам вообще не видна

    programs (local shared, в FAT это system без hidden) - общедоступные программы со своими данными и общими конфигурационными файлами; в обычном режиме можно только читать/исполнять; вложенные объекты также должны иметь этот атрибут (или read-only), иначе будет защищена структура каталога, но не содержимое вложенных в него объектов

    shared data (local shared) - общедоступные данные; в обычном режиме можно только читать

    settings (нет защищающих атрибутов) - персональное конфигурирование и т.п.; физически это разные каталоги

    my data (нет защищающих атрибутов) - персональные данные и, возможно, программы; физически это разные каталоги
  • Who is online

    Users browsing this forum: No registered users and 8 guests