Разработка концептуально новой ОС

Цитата

Количественные ранги - лишнее.
Древовидная иерархия ключей и так дает инструмент ранжирования, причем куда более гибкий, чем числовой ранг.
..Что-то у вас сложно все получается...

IMHO наоборот, это самое простое. Числовой ранг очень просто регулирует отношения.
Не приписывать же к ключу списоу всех разрешенных объектов. Достаточно его описать числом, определяющим право. Но т.к. работа с ключем идет только через хэндл, то регулируются все отношения при их открытии. Проверсятся привилегии процесса, который открывает ключ. Если они >=, то хэндл создается и работа возможно. По-моему нет ничего проще такой архитектуры.

О древовидной структуре - потомок или наследует права или получает меньшие. Большего создать не может. А сама по себе древовидная структура ничего не регулирует.
Это исправит вот этот баг архитектуры.

Цитата

Пример 2. Запуск двух драйверов, разделяющих порт.
Пусть драйвера клавиатуры и мыши используют один порт.
Первым запускается драйвер клавиатуры и "узурпирует" порт. Однако он готов поделиться правами, но только с тем, кто подпишется root\drivers\mouse.

Если драйвер отдаст ключ только тому, кто подпишется каким-то именем (имя получается зашито), то теряется уже даже объектность. Точнее получается монолитное ядро в микроядерной оболочке.

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

На объектном примере.
Есть базовый класс. Есть наследник. Ведь базовый класс не должен знать, что у него есть (будет) определенный наследник.  (Или я ничего не знаю в ООП и иерархии объектов).

Цитата

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

Хм. Если доступны по требованию, то при требовании, где их взять. Значит они должны быть в сообщении (В структуре сообщения. Ее вариант уже предлагал.). Но чтоб память лишний раз не копировать, можно хранить указатель на него.

Цитата rcz, 19.09.03, 13:55:52

Не приписывать же к ключу списоу всех разрешенных объектов.

Не приписывать.
Наоборот! Объекту приписывается список ключей (обычно один), дающих к нему доступ.

Цитата

Достаточно его описать числом, определяющим право.

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

Цитата

По-моему нет ничего проще такой архитектуры.

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

Цитата

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

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

Не знать, а зарезервировать (придумать) любое имя ключа (достаточно одного) для доступа.
Более того, это имя не обязательно зашивать в код - можно прописывать уже при инсталлляции.
И это не обязательно ключ зависимого драйвера - можно создать специальный "свободный" ключ, который МД потом передаст драйверу.
В общем, не вижу, где монолитность - наоборот, связи минимально возможные. Про саму связь ничего не нужно знать заранее, кроме того, что она может быть.

Цитата

На объектном примере.
Есть базовый класс. Есть наследник. Ведь базовый класс не должен знать, что у него есть (будет) определенный наследник.  (Или я ничего не знаю в ООП и иерархии объектов).

ИМХО, все с точностью до наоборот. Как раз в Вашей схеме родитель должен знать о всех потомках, чтобы предоставлять им права. И это ликвидирует всю объектность.

А в ООП объекты в норме используют интерфейсы друг друга.
В приведенном примере ключ выступал в роли абстрактного интерфейса. При этом драйвера вовсе не находились между собой в отношении родитель-потомок, а были в параллельных ветках.

Цитата

Хм. Если доступны по требованию, то при требовании, где их взять. Значит они должны быть в сообщении (В структуре сообщения. Ее вариант уже предлагал.). Но чтоб память лишний раз не копировать, можно хранить указатель на него.

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

Цитата

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

(Не всегда).Хех. Это всегда будет. И в вашей архитектуре. И это правильно.
Доказательство
Если A не >B , и B не > A    =>  A=B. Т.е. у всех приложений будут одинаковые права.
Или вообще не имеют доступа дуг к другу. А отделить хотя бы userа от HDD надо.

Цитата

Не знать, а зарезервировать (придумать) любое имя ключа (достаточно одного) для доступа.
Более того, это имя не обязательно зашивать в код - можно прописывать уже при инсталлляции.

Ладно. Допустим эту ситуацию. Тогда  такая ситуация. Мы имеем базу - дерево, описывающее все драйвера системы. (при установки драйвера, он записывается в правильное место)
/dev/BUS --|-drv1
               |-drv2-|
              ...       -|...
Загружается BUS. Потом какое-то приложение хочет обратиться к drv1. Каким-то образом ядро его загружает (или сама BUS- но этого не надо) и присваивает ключ /dev/BUS/drv1. Права у них получаются одни и те же. Друг с другом общаются безпрепятственно. И в Вашей архитектуре никак не регулируются способы передачи портов. Т.е. потомок драйвера наследует все порты родителя.

      А если драйвер BUS хочет ограничить доступ к себе. Допустим юзер хочет к нему обратиться без прав на это... Это и предлагает моя схема ограничения.

     Объект драйвера, его интерфейс, да и любой ресурс можно открыть, если есть права.

     Так же должны быть как-то разграничены пользовательские объекта(разных пользователей.). Надо добавить какие-то группы. прав пользователей.

Цитата

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

Если один драйвер зависит от другого, то они уже не в паралельных ветках.
Если они в параллельных ветках, логично предполагать, что кто-то захочет ограничить к себе доступ.

    Опишите вашу идею о "Древовидная иерархия ключей и ранжирование". Не вижу в ней никакого ограничения доступа. Учета прав и и.п. (Не ограничеваете же вы доступ из соседних веток.).

Сообщение отредактировано: rcz - 19.09.03, 14:00

[QUOTE=rcz, 19.09.03, 16:27:08]
Если A не >B , и B не > A    =>  A=B. Т.е. у всех приложений будут одинаковые права.[/quote]
Так вот это и плохо. Очевидно, что у разных приложений должны быть разные права - например, когда они запущены разными пользователями...
И вообще, права бывают разными (на разное): у первого приложения больше одних прав, задо у второго больше других - и нельзя их измерить одним числом.

[quote] Тогда  такая ситуация. Мы имеем базу - дерево, описывающее все драйвера системы. (при установки драйвера, он записывается в правильное место)
/dev/BUS --|-drv1
               |-drv2-|
Загружается BUS. Потом какое-то приложение хочет обратиться к drv1. Каким-то образом ядро его загружает (или сама BUS- но этого не надо) и присваивает ключ /dev/BUS/drv1.[/quote]
Как приложению можно присвоить ключ, назначенный драйверу?? Ключ может быть сопоставлен только одному объекту.
Сопоставление подразумевает владение, но не наоборот. А владение нужно только, чтобы иметь право выступать от имени объекта (но не обязательно им быть).

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

[/quote] И в Вашей архитектуре никак не регулируются способы передачи портов. Т.е. потомок драйвера наследует все порты родителя.[/quote]
Нет. Потомок вообще ничего не наследует.
Наоборот, предок имеет все права потомка (правда, есть спорные моменты)
А регулирование везде одинаково - по подписи на запросе.

[quote] А если драйвер BUS хочет ограничить доступ к себе. Допустим юзер хочет к нему обратиться без прав на это...[/quote]
Ограничить не может, но он вправе (и обязан) просто игнорировать сообщения с "мелким" ключом в подписи.

Есть проблема "спама" - когда одно приложение может практически подвесить другое, подряд заваливая сообщениями. Но, кажется, есть решение: на каждое сообщение забирать у отправителя некоторый фиксированный квант времени (достаточный по крайней мере для опознания адресов) и передавать его в ресурс получателя.

[quote]Объект драйвера, его интерфейс, да и любой ресурс можно открыть, если есть права.[/quote]
Это разные подходы. У меня просто нет понятия "открыть", а права проверяются на каждое действие..

[quote]Так же должны быть как-то разграничены пользовательские объекта(разных пользователей.). Надо добавить какие-то группы. прав пользователей.[/quote]
Группы естественным образом возникают из иерархии ключей: владение ключом означает владение и всеми его потомками.

[quote]Опишите вашу идею о "Древовидная иерархия ключей и ранжирование". Не вижу в ней никакого ограничения доступа. Учета прав и и.п. (Не ограничеваете же вы доступ из соседних веток.).[/quote]
Идея в том, что защита обеспечивается не ограничением доступа, а отказом выполнять запрос, не подписанный нужным ключом.
То есть каждый может обратиться к начальнику, но не каждого он будет слушать. А кого слушать, решает сам.
Вы же предлагаете вообще не пускать в кабинет, кого не надо. Но кто будет решать, кого надо. Секретарша?

Цитата

Ограничить не может, но он вправе (и обязан) просто игнорировать сообщения с "мелким" ключом в подписи.

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

Да и вообще опишите, что вы имеете в виду под "подписью сообщения".

Цитата rcz, 20.09.03, 01:41:29

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

Это практически нереализуемо.
Хэндлы выдает ядро - а ему откуда знать, кто на что имеет право?! Если всю безопасность свалить на ядро, оно будет вовсе не "микро".
Проще, надежнее и гибче, когда драйвер сам решает, какие запросы обрабатывать.
Например, для драйвера ФС иначе и не сделать - к нему могут обращаться любые приложения; но будут ли удовлетворены их запросы - зависит от того, к какому файлу запрос. То есть запретить (или ограничить) отправку сообщений к ФС невозможно.

Поэтому для предотвращения спама остается только метод перераспределения ресурса процессора. Но он вполне эффективен.

Цитата

Да и вообще опишите, что вы имеете в виду под "подписью сообщения".

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

Этот пример, правда, не совсем точен. В ОС это бы выглядело чуть иначе: директор не подписывает заявление, а дает (заранее) заявителю одну из своих печатей, которую тот сам прикладывает. Причем печати можно сколько угодно копировать, и их много видов (на каждый вид заявления может быть своя).

То есть, подпись сообщения - это "прикладывание печати" (указание одного из ключей, находящихся во владении).

Получаем возможность почти как угодно управлять правами: нужно лишь правильно предоставлять "печати" (ключи).

Цитата nvm, 18.09.03, 23:41:41

Термин "владения" ключом введен строго: владеть ключом значит иметь право посылать сообщения от его имени. Это как печать, заверяющая подлинность документа, или подпись.
Для этого в сообщении и различаются ключ подписи и обратный адрес. Все как в жизни: не обязательно кто подписал письмо, тот его и пересылает. И юридически важно именно кто подписал.
Право владения принадлежит создателю и передается только явным системным вызовом.

Извините, но у меня другое представление о ключах.

Цитата nvm, 18.09.03, 23:41:41

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

Хорошо. Вот мои термины:

Capability - designates an object and gives the program the authority to perform a specific set of actions on that object. Two capabilities can designate the same object but authorize different sets of actions.

Capabilities can be delegated.
Capabilities can be copied.
Capabilities are not unforgeable.

Programs running in capability systems hold some representations of authority called keys.

Keys are tokens of authority. A program may only cause actions warranted by the keys it holds (т.е. если она "владеет ключом"). Any action that a program causes is enabled by some key that it holds and explicitly identifies in an invocation of that key.

The term capability was introduced by Dennis and Van Horn in 1966 in a paper entitled Programming Semantics for Multiprogrammed Computations.

Цитата nvm, 18.09.03, 23:41:41

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

Совершенно неправильная точка зрения, потому что здесь хэндл и выступает в роли Capability. Capability Systems предоставляют превосходные средства защиты. С этим трудно не согласиться, если подумать же такое handle на самом деле.

Цитата nvm, 18.09.03, 23:41:41

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

См. определение Capability.

Цитата nvm, 18.09.03, 23:41:41

..Насчет ограничения доступа к ключам - возникает ощущение, что подход пока не проработан.
А раз так, то естественно было бы сначала критически разобрать то, что уже проработано хотя бы в общих чертах (см. бюллетень). Изложение там, конечно, краткое, но любой сценарий работы этой схемы я могу развернуть.
Идея состоит в том, что объекты могут посылать сообщения, кому угодно. Все, как у людей: написать письмо можно, хоть кому, и попросить, о чем угодно.. Но рассчитывать на исполнение просьбы можно только, если твоя подпись для получателя что-то значит.

Моё личное мнение: capability systems во всех отношениях лучше предлагаемой вами трактовки ключа.
Я уже устал критиковать вашу спецификацию.

Цитата nvm, 18.09.03, 23:41:41

Объект должен иметь интерфейс - а какой интерфейс у памяти?? К тому же объект подразумевает активность - а память пассивна по определению.
Поэтому, ИМХО, не нужно усложнять. Как раз здесь одних хэндлов будет предостаточно.

Разделяемую память можно рассматривать как объект. Объект не всегда подразумевает активность.
И вообще, посмотрите EROS - там всё имеет свои интерфейс.

Цитата nvm, 18.09.03, 23:41:41

Смотря с какой стороны смотреть.. ключ - это интерфейс, т.е. класс, т.е тип.

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

Цитата nvm, 18.09.03, 23:41:41

А объекты windows - все безымянны (кроме файлов).

HANDLE CreateEvent(
 LPSECURITY_ATTRIBUTES lpEventAttributes,
 BOOL bManualReset,
 BOOL bInitialState,
 LPCTSTR lpName
);

HANDLE CreateMutex(
 LPSECURITY_ATTRIBUTES lpMutexAttributes,
 BOOL bInitialOwner,
 LPCTSTR lpName
);

HANDLE CreateSemaphore(
 LPSECURITY_ATTRIBUTES lpSemaphoreAttributes,
 LONG lInitialCount,
 LONG lMaximumCount,
 LPCTSTR lpName
);

HANDLE CreateWaitableTimer(
 LPSECURITY_ATTRIBUTES lpTimerAttributes,
 BOOL bManualReset,
 LPCTSTR lpTimerName
);

Иногда полезно читать MSDN Library

Цитата nvm, 18.09.03, 23:41:41

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

Это вопрос рациональности предлагаемой архитектуры ОС.

Цитата nvm, 19.09.03, 00:17:01

2villmor
А где Вы предлагаете читать про теорию ключа?

А вы где про неё читали?

Цитата nvm, 06.09.03, 20:24:36

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

The term capability was introduced by Dennis and Van Horn in 1966 in a paper entitled "Programming Semantics for Multiprogrammed Computations".

Dennis and Van Horn, "Programming Semantics for Multiprogrammed Computations", Communications of the ACM, Volume 9, Issue 3
Pages: 143 - 155
Year of Publication: 1966
ISSN:0001-0782

К сожалению, доступ к этой публикации небесплатен, но и без неё в интернете я нашёл немало интересных документов. Есть даже целые книги в формате PDF. Вот некоторые ссылки:

[link=http://www.eros-os.org/essays/capintro.html]What is a Capability, Anyway?[/link]
[link=http://www.eros-os.org/essays/wherefrom.html]Where Capabilities Come From[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html]The Confused Deputy[/link]
[link=http://www.eros-os.org/essays/ACLSvCaps.html]Comparing ACLs and Capabilities[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/Wells.html]A Note on "Protection Imperfect"[/link]
[link=http://zesty.ca/capmyths/]Capability Myths Demolished[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/Confinement.html]A Note on the Confinement Problem[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/Security.html]Security in a Secure Capability-Based System[/link]
[link=http://www.cs.washington.edu/homes/levy/capabook/]Capability-Based Computer Systems[/link]
[link=http://cs.unomaha.edu/~stanw/papers/gasser/]CSCI 8920 - Trusted Systems - Spring 2003[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/Patent/Patent.html]U.S. Patent 4,584,639[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/Gnosis/Gnosis.html]GNOSIS: A Prototype Operating System for the 1990's[/link]
[link=http://www.eros-os.org/pipermail/cap-talk/1999-October/000480.html]Hybrid capability systems[/link]
[link=http://www.cap-lore.com/CapTheory/KK/ModCap/]Modified Capability Systems?[/link]
[link=http://srl.cs.jhu.edu/~shap/EROS/hp-talk/sld008.htm]Types of Capability Systems[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/OSRpaper.html]The KeyKOS Architecture[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html]The KeyKOS Nanokernel Architecture[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/agorics/KeyKos/Concepts/welcome.html]Introduction to KeyKOS Concepts[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/agorics/KeyKos/principles/Principles.html]KeyKOS Principles of Operation[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/KeyTXF/KeyTXF.html]Object Oriented Transaction Processing in the KeyKOS Microkernel[/link]
[link=http://www.eros-os.org/pipermail/eros-arch/2002-February/003245.html]Exposing key structure to applications?[/link]
[link=http://oppcos.sourceforge.net/]Oppcos - The orthogonally persistent pure capability operating system[/link]
[link=http://www.cis.upenn.edu/~KeyKOS/]KeyKOS Home Page[/link]

RTFM!

Сообщение отредактировано: vilmor - 20.09.03, 20:48

Цитата Vilmor, 21.09.03, 00:20:53

Извините, но у меня другое представление о ключах.

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

Цитата

Хорошо. Вот мои термины:

Capability - designates an object and gives the program the authority to perform a specific set of actions on that object. Two capabilities can designate the same object but authorize different sets of actions.

Capabilities can be delegated.
Capabilities can be copied.
Capabilities are not unforgeable.

Programs running in capability systems hold some representations of authority called keys.

Keys are tokens of authority. A program may only cause actions warranted by the keys it holds (т.е. если она "владеет ключом"). Any action that a program causes is enabled by some key that it holds and explicitly identifies in an invocation of that key.

Вроде как, это определение применимо и к ключу в моем понимании (правда, я не знаю перевода для "unforgeable").
Только у меня ключ - это в первую очередь Имя (уникальный идентификатор объекта, однозначно определяющий его интерфейс), и только по совместительству ключ - средство доступа.

Цитата

Совершенно неправильная точка зрения, потому что здесь хэндл и выступает в роли Capability. Capability Systems предоставляют превосходные средства защиты.

Превосходные.. Но у меня лучше  8) ..ИМХО  ;D

Цитата

Моё личное мнение: capability systems во всех отношениях лучше предлагаемой вами трактовки ключа.
Я уже устал критиковать вашу спецификацию.

Лучше или нет - доказать не могу.
Но ясно одно: существующие концепции capability systems НИКУДА НЕ ГОДЯТСЯ. И этот факт строго доказывается тем, что до сих пор существует Windows. Система безобразная, но все остальные - НЕ ЛУЧШЕ, иначе бы они давно ее вытеснили.

Но главный довод: ваши варианты capability systems уже реализовывались раньше.
Кому как, но мне не интересно делать то, что кто-то уже реализовывал.
Я не могу навязывать свои идеи. У кого есть - предлагайте СВОИ. С чужими идеями тоже нужно знакомиться, но в первую очередь, чтобы не посторяться, и в последнюю - чтобы заимствовать бесспорно удачные находки, УМЕСТНЫЕ в рамках развиваемой новой концепции.

Поэтому напоминаю тему: основная идея ОС должна быть НОВОЙ - то есть никем никогда не реализованной даже в виде прототипа.
Не настаиваю, чтобы эта идея была моей.
Если кто предложит свое, но действительно новое - готов присоединиться.

А для проектов типа "давайте еще раз реализуем KeyKOS", я бы лучше открыл другую тему, чтобы не смешивать цели.

Цитата

Разделяемую память можно рассматривать как объект. Объект не всегда подразумевает активность.
И вообще, посмотрите EROS - там всё имеет свои интерфейс.

По правилам ООП любой доступ к объекту должен осуществляться через методы класса.
Это получается, что для доступа к разделяемой памяти придется делать syscall-ы.
Но тогда теряется смысл разделяемой памяти - предоставление эффективного доступа без лишнего копирования и syscall-ов.

Цитата

Ключ - это НЕ интерфейс, НЕ класс и НЕ тип. Это - реализация интерфейса, объект класса, переменная заданного типа.

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

ИМХО, абстракция ключа ближе к понятию класса, нежели объекта, хотя в-точности ни с одним не совпадает.

Цитата

Иногда полезно читать MSDN Library

Да.. иногда  ;)
Но для всех этих объектов есть и безымянные варианты.. как-то я ими и обходился.
..Буду знать.  :)

Цитата

А вы где про неё читали?
The term capability was introduced by Dennis and Van Horn in 1966 in a paper entitled "Programming Semantics for Multiprogrammed Computations".

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

[offtopic]
Читая на досуге Брукса.
"Концептуальная целосьность является важнейшей характеристикой системного проекта...
проблемы:
-  как достич концептуальной целостности?
-  не будет ли это причиной ракола на элиту, аристократический класс архитекторов - с одной стороны, и толпы плебеев-исполнителей, чьи творческие таланты и идеи подавляются, - с другой?
- Как удержать архитекторов от витания в облаках и разработки неосуществимых или чрезмерно дорогих спецыфикаций ?
- Как добиться того, чтобы любая мелочь из созданной архитектором спецификации дошла до исполнителя, была им правильно понята и точно внедрена в продукт?"
[/offtopic]

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

    Распишите алгоритмом работу с ключами. Момент от его создания до обработки запроса. И проверку "подписей"(по подроюней). Тогда может всем станет понятней, что имеется в виду. Заодно, может быть, найдете свои ошибки.,

Цитата

То есть, подпись сообщения - это "прикладывание печати" (указание одного из ключей, находящихся во владении).

Совсем не понятна проверка прав отправителя в этом случае. Не будет же он хранить у себя весь список допущенных к себе.

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


Действительно получается неоднозначность.

Цитата

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

В моем понимании ключ - это описатель доступа к объекту, интерфейсу объекта. Поэтому получается, что он должен быть уникальным в системе. Хэндлы нужны только для ускорения доступа, действителен только внутри одного процесса.  (Проводится аналогия с COM. ).

Нужно разбирать хотя бы по частям, начиная снизу. Чтоб складывалась единая концепция и архитектура. Слушаю ваши идеи о рабте системы.

Сообщение отредактировано: rcz - 21.09.03, 22:37

Цитата rcz, 22.09.03, 02:35:35

Читая на досуге Брукса.  
"Концептуальная целостность является важнейшей характеристикой системного проекта...
проблемы:

Хорошо быть авторитетом - можно с умным видом говорить очевидные вещи

Цитата

-  не будет ли это причиной ракола на элиту, аристократический класс архитекторов - с одной стороны, и толпы плебеев-исполнителей, чьи творческие таланты и идеи подавляются, - с другой?  

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

Цитата

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

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

Цитата

Так что, уважаемые Архитекторы

В таких проектах все участники - архитекторы

Цитата

Распишите алгоритмом работу с ключами.

Кажись я понял, в чем принципиальное отличие предлагаемого подхода от стандартного.

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

Теперь отличие.
В общепринятом подходе ключ доступа к сервису является ключом объекта, предоставляющего сервис.
В предлагаемом подходе ключ доступа к сервису является ключом объекта, ЗАПРАШИВАЮЩЕГО сервис. Это значит, что имея ключ объекта, мы не обязательно имеем к нему доступ - зато имеем доступ ко всему, что доступно объекту.
В первом случае объект всегда хранит (не сам, а в системном дескрипторе) список объектов, к которым он имеет доступ.
Во втором случае - объектов, которые имеют к нему доступ.

Объем хранимой информации в обоих подходах одинаков.
И в обоих случаях, очевидно, что все мыслимые объекты перечислить нереально.
Поэтому делается оптимизация.
В обоих методах вводится иерархия ключей: ключ верхнего уровня предоставляет доступ всех ключей нижнего.
Но только второй подход позволяет, чтобы один ключ давал доступ к нескольким объектам (и при этом ключи оставались уникальными идентификаторами!).

И главное преимущество второго подхода: объект сам решает, кого к себе допустить - об этом не нужно заботиться и следить "кому-то сверху".

Еще преимущество в концептуальной стройности: определение ключа теперь не связано с доступом; ключ - просто защищенный идентификатор.

Цитата

Совсем не понятна проверка прав отправителя в этом случае. Не будет же он хранить у себя весь список допущенных к себе.  

Надо понимать "он" - это получатель?
Тогда будет. В этом ничего нет страшного, любая стандартная архитектура требует, чтобы объект "помнил" всех, к кому он имеет права доступа - по трудоемкости это эквивалентно.
Но, обращаю внимание, что "все, имеющие право доступа" - это очень небольшой список (несколько имен), так как ключи можно передавать.

Цитата

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

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

Цитата

В моем понимании ключ - это описатель доступа к объекту, интерфейсу объекта.

Придумал новую аналогию: ключ - это точное название (идентификатор) должности.
Человеческие отношения (деловые) построены на концепции должностей.
Совпадение понятий ключа и должности почти полное!
Например, передача ключей эквивалентна делегированию должностных полномочий - и важный момент, что получивший полномочия выступает в РОЛИ того, кто их дал.

Цитата

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

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

Цитата

Слушаю ваши идеи о работе системы.

Идеи-то в бюллетне изложены полностью. Там практически полная спецификация ядра (может, 20\% функций забыто).
Я не знаю, что именно нужно детализировать - может, кто сформулирует вопросы?

Цитата

Придумал новую аналогию: ключ - это точное название (идентификатор) должности.
Человеческие отношения (деловые) построены на концепции должностей.
Совпадение понятий ключа и должности почти полное!
Например, передача ключей эквивалентна делегированию должностных полномочий - и важный момент, что получивший полномочия выступает в РОЛИ того, кто их дал.

На объектах ядра понятней было бы

Цитата

И главное преимущество второго подхода: объект сам решает, кого к себе допустить - об этом не нужно заботиться и следить "кому-то сверху".

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

Цитата

В первом случае объект всегда хранит (не сам, а в системном дескрипторе) список объектов, к которым он имеет доступ.
Во втором случае - объектов, которые имеют к нему доступ.

Откуда первоначально у объекта появляется список разрешенных объектов?

Далее, если этот объект - какая-нибудь разделяемая библиотека, к которой должны иметь доступ все, не будет эе она хранить все объекты системы в своем списке.

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

Цитата

Но, обращаю внимание, что "все, имеющие право доступа" - это очень небольшой список (несколько имен), так как ключи можно передавать.

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

ACL- мне кажется не очень гибким и плохо настраиваемым. Хотя могу просто представить, что в системе будет просто-напросто  находиться мало ключей. И многии объекты будут сидеть с одними и теми же ключами. А вспоминая это

Цитата

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

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

З.Ы. Capabilities - оптимизированый ACL. Не понимаю, почему вы его отбрасываете.

Итак. Опишите свой выриант НАСТРОЙКИ этой системы.

Цитата

Хоть на чем-то иногда сходимся

Все здесь на многом сходимся. Но не понимаем друг друга

Цитата rcz, 22.09.03, 23:15:44

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

Это дополнительная (и ИМХО важная) возможность, которой никто, однако, не заставляет пользоваться. Предложенная схема полностью включает стандартные capacities, как частный случай. Для этого все объекты нужно делать реагирующими только на свой ключ.

Цитата

Если это не контролтруется системой, то подпись он может взять любую и получить полный доступ к объекту.

По-умолчанию, программа может подписаться только собой (или потомками) - другие ключи ей может дать лишь кто-то, кто ими владеет (если "захочет").

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

Цитата

И если в программе используется очень много объектов - не запомнишь ведь все требуемые ключи.

Уж если интерфейс объекта запомнишь, то один ключ к нему - тем более.

Цитата

Откуда первоначально у объекта появляется список разрешенных объектов?

Которые к нему имеют доступ (лучше не доступ, а доверие, потому что доступ всегда есть у всех) ?
Из параметров, хранимых в реестре. Что-то может быть зашито в код.

Цитата

Далее, если этот объект - какая-нибудь разделяемая библиотека, к которой должны иметь доступ все, не будет эе она хранить все объекты системы в своем списке.

Она вообще не будет смотреть на подписи, а будет обслуживать всех.

Цитата

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

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

Цитата

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

Ключ всегда динамический.
А пользователь ключа не имеет. Пользователь - это набор ключей, которые приложение (представитель пользователя) получает после регистрации у менеджера.

Цитата

Допустим все процессы - имеют один ключ(обеспечивают один интерфейс - тем правилам не противоречит), у них одинаковые права.

Нет. Ключ может быть связан не более, чем с одним потоком. Имелось в виду, что после завершения процесса можно запустить другой с тем же ключом.
Аналогия с должностями действительно очень точная: директор всегда один, но в разное время им могут быть разные люди.

Цитата

(ведь имея несколько ключей можно подписываться разными).

Так в том и гибкость - это и в классике так.

Цитата

З.Ы. Capabilities - оптимизированый ACL. Не понимаю, почему вы его отбрасываете.

Не отбрасываю. Он реализуем как частный случай.

[quote]Итак. Опишите свой выриант НАСТРОЙКИ этой системы.[quote]
Попробую.. Описать минимальную конфигурацию компонент.

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

Теперь оптимизация.

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

К примеру возьмем файловую систему(самый сложный, может неудачный, пример). Откроем хэндлы интерфейсов open, read, write. Если есть права на них- объект получит хэндлы и вместе с ними возможность к ним обращаться.

Далее при обращение по хэндлам open будет проверять подпись, а при дальнейшем обращении к read,write не стоит (ФС будет основываться на внутреннем хэндле открытого файла).

Т.Е. получаем, что если мы имеем открытый хэндл, мы можем обращаться к интерфейсу объекта.  А сам интерфейс - может проверять, а может и нет.

В итоге получаем, что защита делится на 2 уровня.
1 - контролируется системой - сама возможность обратиться к интерфейсу, получение хэндла
2 - на уровне объектов. Может отсутствовать. Объект при обработке вызова может дополнительно проверять подписи.

Чтоб не было больших ACL , можно действительно допустить к себе в доверие не очень большое количество объектов (суть получается почти capabilities) . О процессы будут требовать ключи доступа у них.

Сообщение отредактировано: rcz - 23.09.03, 07:54

Структуры ядра.

Ключи предлагаю организовать следующей структурой
struct key_tree{
     key_tree *parent;
     list<key_tree> childs;
     char *ID;
     OBJECT *ItsObject;
     dword RefCount;
}
Все это дерево хранится в памяти ядра.

struct OBJECT{
     key_tree * myKey;
     list<HandlKeyIndex> ACL;
     list<HandlKeyIndex> sign;
    ...
}

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

Объект содержит указатель на лист этого дерева (так определяется его ключ), ACL, и Sign - список ключей  - подпись, "олицитворение".

Интерйейс - тоже объект.

Хэндл объекта -  суть хэндл ключа.

Подпись и ACL - список описателей ключей (хэндлов).

Все эти объект описаны с точки зрения управления объектами в ядре.

Таблица хэндлов у каждого процесса своя и она не доступна юзеру для непоследственного обращения.

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


функции
AddKeyToACL(char *key);//добавляет хэндл ключа в список доверия(ACL в структуре объекта).

RemoveKeyFromACL(char *key);

AddKeyToSign(char *key); //Проверяет права на ключ(доверие к нему), и добавляет хэндл ключа в список подписей(sign в структуре объекта).
RemoveKeyFromSign(char *key);

BOOL IsKeyInSign(HANDLE hObj,HANDLE hKey);

BOOL VerifyAccess(HANDLE object); //проверка ядром доступа к проверяющему. Сравнение ACL и Sign.

void GetKey(HANDLE hKey,char *key,WORD bufferLen);// получение идентификатора ключа.

HANDLE OpenKey(char *key);//открытие ключа


Права доступа к объекту определяет администратор. При создании пользователя, создается и его ключ. Если он хочет допустить пользователя к объекту, он добавляет этот ключ в его ACL.
Когда пользователь входит в систему, каждому его приложению в подпись вносится его ключ.
Ключи в дерево добавляются при запуске приложения. И чтоб не было противоречий с хэндлами из ACL, эти ключ тоже создаются, но указатель на OBJECT =NULL, RefCount=1. Когда некий OBJECT будет создавать ключ, система, если найдет, что ключ уже есть, будет смотреть на OBJECT !=NULL, иначе не создаст. Refcount увеличивает на 1.

Удаляются ключи из дерева, если RefCount становится 0.

Цитата rcz, 23.09.03, 01:27:03

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

Все так, только в подписи предлагаю ограничиться одним ключом - получаем в сообщении всегда ровно три ключа.

Цитата

Теперь оптимизация.

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

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

Цитата

К примеру возьмем файловую систему(самый сложный, может неудачный, пример). Откроем хэндлы интерфейсов open, read, write. Если есть права на них- объект получит хэндлы и вместе с ними возможность к ним обращаться.

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

Цитата

Далее при обращение по хэндлам open будет проверять подпись, а при дальнейшем обращении к read,write не стоит (ФС будет основываться на внутреннем хэндле открытого файла).

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

Поэтому проверка подписи обязательна при любом обращении - но это быстрая операция.

Цитата

В итоге получаем, что защита делится на 2 уровня.
1 - контролируется системой - сама возможность обратиться к интерфейсу, получение хэндла
2 - на уровне объектов. Может отсутствовать. Объект при обработке вызова может дополнительно проверять подписи.

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

Цитата

Чтоб не было больших ACL , можно действительно допустить к себе в доверие не очень большое количество объектов (суть получается почти capabilities) . О процессы будут требовать ключи доступа у них.

Если объекты будут воспринимать только сообщения, подписанные их собственным ключом (остальные игнорировать) - это будет В ТОЧНОСТИ capabilities.
Но поскольку объекты могут иметь и другое поведение, получается дополнительная гибкость.