[gl00mie]

Цитата:

Сообщение от sukhanchik

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

Насколько я понимаю, принцип примерно такой:

• по ходу выполнения кода клиентом API запрашиваются разрешения на выполнение тех или иных действий (создается экземпляр CodeAccessPermission и дергается assert()) - это приводит к тому, что в стеке вызовов создается некий security cookie (видел такой термин в отладочной информации ядра 4-ки), соответствующий запрошенным разрешениям
• выше по стеку вызовов клиента API вызывается код, который использует некий API, требующий разрешений - при этом владелец API создает соотв. экземпляр класса-наследника CodeAccessPermission и дергает на нем метод demand()
• ядро пробегается по стеку вызовов вниз и ищет соотв. security cookie; соответствие определяется тем, что созданному во владельце API экземпляру класса-наследника CodeAccessPermission в метод isSubsetOf() подсовываются экземпляры запрошенных разрешений (созданных в клиенте API классов-наследников CodeAccessPermission)
• если в какой-то момент созданный владельцем API экземпляр вернет из isSubsetOf() true, то считается, что разрешение найдено, и дальше выполняется код API, следующий за вызовом demand()
• если на протяжении всего стека вызовов клиента API подходящий security cookie не найден, ядро выбрасывает исключение
• если код клиента API выходит из метода, в котором было запрошено разрешение (вызван assert()), то на созданных разрешениях вызывается revertAssert(), и security cookie удаляются; revertAssert() можно, конечно, вызвать и раньше, не дожидаясь выхода из метода. Таким образом, код клиента API, в который вернется управление из метода, запросившего разрешение, уже не сможет воспользоваться этим разрешением, потому что оно будет отсутствовать в стеке вызовов

В общем, смысл в том, что разрешение, если идти по стеку вызовов, должно быть получено раньше, чем будет использован соотв. API, вот и все.

Цитата:

Сообщение от sukhanchik

2. Проверка, что вызов опасного API был вызван из "доверенного" кода, сохраненного в АОТ. А какой код не доверенный? Не сохраненный в АОТ?. Интересно - во-первых - как такой код исполняется (в Аксапте) и даже не столько это, а сколько то, что в Аксапте так просто создать код, сохраненный в АОТ и вызвать "опасный" код оттуда - что при желании так сделать - это сделать все равно можно.

Насколько я понимаю, "ноги" этих разрешений растут из .NET с его managed code. Не забывайте, что как код Х++ может вызывать .NET-сборки, так и внешний код может вызывать код Х++ через Business Connector, может, дело в этом...

Цитата:

Сообщение от sukhanchik

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

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

Цитата:

Сообщение от sukhanchik

Но тут и вопрос - если самому писать - то зачем тогда поддержка на уровне ядра?

Ради взаимодействия с CLR