ошибка обращения к .NET сборке в режиме Server

[GromRom]

Здравтвуйте коллеги!

Написал X++ код (DAX 4.0), который обращается к прокси-сборке web-сервиса узла SharePoint.

Если данный код работает со свойством RunOn == 'Called from' - то всё ок!
Если данное свойство поменять на Server, то выдаются вот такие страшные ошибки:

Сбой запроса на разрешение типа "InteropPermission".
(S)\Classes\InteropPermission\demand
(S)\Classes\CLRObject\new
(S)\Classes\ImportContractApprovalInfo_NV\new - line 24
(S)\Classes\ImportContractApprovalInfo_NV\main - line 38

Объект "CLRObject" не может быть создан

Вот эти самые line 24:

 //внешняя прокси-сборка, позволяющая работать с web-сервисом
    ImortApprovalInfo.ApprovalDocuments_ListService.Lists _listService;
;
  _listService = new ImortApprovalInfo.ApprovalDocuments_ListService.Lists();

1) что не так ?
2) как исправить?

[Yprit]

http://msdn.microsoft.com/en-us/library/bb190039.aspx

[GromRom]

Цитата:

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

http://msdn.microsoft.com/en-us/library/bb190039.aspx

Спасибо за ссылку!

Вставил пермишны:

   //проверяем возможность доступа к сборке
    perm = new InteropPermission(InteropKind::ClrInterop);
    if (perm == null)
    {
        return;
    }
    perm.assert();

После чего cборка начала работать в режиме "Server"

Однако обнаружил следующее некорректное поведение компонента ClrInterOp

Метод ClrInterop::isNull в режиме "Server" выдаёт стабильно true! Хотя, как видно из кода ниже, строка strOuterXml ВСЕГДА имеет осмысленные данные (ID="{BB80822A-7849-416B-9BF4-ECD83999F867}).

В режиме "Client" метод ClrInterop::isNull работает нормально, и выдаёт true или false в зависимости от реального сотояния объекта.

    System.Xml.XmlAttributeCollection  xacAttributes;
    System.Xml.XmlAttribute            xaAttribute;
 
    str strOuterXml;
    anytype ant;
    ;
 
    xacAttributes = ndListDefinition.get_Attributes();
    xaAttribute  =  xacAttributes.get_ItemOf("ID");
    strOuterXml = ClrInterOp::getAnyTypeForObject(xaAttribute.get_OuterXml());
    ant = ClrInterop::isNull(xaAttribute);
 
    if(!ClrInterop::isNull(xaAttribute))
    {
         _listID = xaAttribute.get_Value();
    }
    else
    {
        _listID = "-1";
    }

[b_nosoff]

Цитата:

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

Однако обнаружил следующее некорректное поведение компонента ClrInterop

Метод ClrInterop::isNull в режиме "Server" выдаёт стабильно true!

В режиме "Client" метод ClrInterop::isNull работает нормально, и выдаёт true или false в зависимости от реального сотояния объекта.

кстати, а никто не победил это поведение на четверке?

[kashperuk]

Ошибки не странные. Почитайте про Code Access Security, к примеру здесь:
http://msdn.microsoft.com/en-us/library/bb190039.aspx

О. Точно такая же ссылка выше

[sukhanchik]

Вот у меня та же проблема возникла, только при использовании ADO. (там использовался класс InteropPermission с типом InteropKind::ComInterop). Т.е. хоть тресни - не выдается разрешение при работе на сервере. Я не знаю - баг это или фича или я просто "не умею готовить", однако - этого поведения достаточно - чтобы я для себя сказал - мне эти разрешения не нужны - и хорошо - что есть возможность их отключить на уровне АОСа... и вообще - эти разрешения - есть вредная и дурацкая приблуда (совершенно не вижу логики в их наличии - только дополнительный код писать приходится).

Может конечно я и резко высказался - но пока я как-то не осознал их полезность и не понял - какой плюс - хотя бы с маркетинговой т.з. они привносят

Для отключения этих разрешений на уровне АОСа в реестре (конфигурации) нужно указать у параметра caslevel значение disable

PS. В приведенной ссылке выше написано "Code Access Security (CAS) helps protect APIs that have potential security risks ", т.е. как бы разрешения позволяют какие-то риски снизить. Вопрос. Какие риски можно снизить - если все равно все вызовы обрамляются в разрешения???. Т.е. теперь типа если увидел разрешения - значит есть некий потенциально рисковый вызов?. Если не обрамить вызов в разрешение - то вызова не произойдет. Вот я не понимаю этого искусственно выдуманного кода. Код-то не машина пишет - а человек

[gl00mie]

Цитата:

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

В приведенной ссылке выше написано "Code Access Security (CAS) helps protect APIs that have potential security risks ", т.е. как бы разрешения позволяют какие-то риски снизить. Вопрос. Какие риски можно снизить - если все равно все вызовы обрамляются в разрешения???. Т.е. теперь типа если увидел разрешения - значит есть некий потенциально рисковый вызов?. Если не обрамить вызов в разрешение - то вызова не произойдет. Вот я не понимаю этого искусственно выдуманного кода. Код-то не машина пишет - а человек

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

[sukhanchik]

Цитата:

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

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

Когда тебя двадцать раз спрашивают - это конечно напрягает - но смысл понять можно. Но когда ты пишешь код - то компилятор тебя двадцать раз не спрашивает. Да и в общем-то (как мне кажется) - одно дело Виста, которой пользуются миллионы пользователей разного уровня компьютерной грамотности и другое дело код Х++, которым пользуются (с т.з. разработки) в общем-то те люди, которые по определению понимают что они делают.
А потом - что значит "лишний раз подумать"? Если мне надо вызвать какую-то WinAPI-функцию или функцию из dll - что я сделаю? Ctrl+C, Ctrl+V из того места, где она работает и исправлю имя функции. Ну еще проверю - что все вызывается. Ну и какая разница сколько строчек кода я скопирую не глядя?

Единственное - что меня смущает - это Ваш ответ про метод assert. Т.е. каким образом предполагается (предполагалось) контролировать - в каких условиях используется "опасное" API?
Т.е. Windows будет контролировать - где можно вызывать функцию к примеру WinAPI::findWindow, а где нельзя - так что ли? Чего-то не врубаюсь. И интересно еще как это все ложится на Аксапту - где метод assert() ядерный...

[Yprit]

Цитата:

Microsoft Dynamics AX code access security allows developers to protect dangerous APIs from being invoked by untrusted code (code that does not originate from the Application Object Tree (AOT)). Code access security does this by performing the following actions:
1. It verifies that the code asserted the appropriate permission on the call stack to use the dangerous API.
2. It verifies that the assert (the request to use the dangerous API) was executed in trusted code and saved in the AOT.
3. It verifies that the assert was executed on the same tier as the dangerous API.
For Dynamics AX version 4.0, code access security covers the use of dangerous APIs on the server tier only. You do not need to modify or mitigate client-only invocations of dangerous APIs.

см. также http://msdn.microsoft.com/en-us/library/930b76w0.aspx - ноги растут оттуда

Цитата:

To help protect computer systems from malicious mobile code, to allow code from unknown origins to run with protection, and to help prevent trusted code from intentionally or accidentally compromising security, the .NET Framework provides a security mechanism called code access security. Code access security allows code to be trusted to varying degrees depending on where the code originates and on other aspects of the code's identity. Code access security also enforces the varying levels of trust on code, which minimizes the amount of code that must be fully trusted in order to run. Using code access security can reduce the likelihood that your code can be misused by malicious or error-filled code. It can reduce your liability because you can specify the set of operations your code should be allowed to perform as well as the operations your code should never be allowed to perform. Code access security can also help minimize the damage that can result from security vulnerabilities in your code.

[GromRom]

Цитата:

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

см. также http://msdn.microsoft.com/en-us/library/930b76w0.aspx - ноги растут оттуда

Так почему же такое разное поведение метода в режимах "Client" и "Server" ???

[gl00mie]

Цитата:

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

Так почему же такое разное поведение метода в режимах "Client" и "Server" ???

Ну вот же написано в документации:

Цитата:

For Dynamics AX version 4.0, code access security covers the use of dangerous APIs on the server tier only. You do not need to modify or mitigate client-only invocations of dangerous APIs.

[Yprit]

Цитата:

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

Так почему же такое разное поведение метода в режимах "Client" и "Server" ???

Вообще-то мой пост был ответом sukhanchik'у

По приведенному куску кода однозначно сказать сложно. А что возвращает

CLRInterop::isInitialized(xaAttribute)

?

[sukhanchik]

Цитата:

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

1. It verifies that the code asserted the appropriate permission on the call stack to use the dangerous API.
2. It verifies that the assert (the request to use the dangerous API) was executed in trusted code and saved in the AOT.
3. It verifies that the assert was executed on the same tier as the dangerous API.

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

Т.е. как бы получается - что эта проверка в общем-то ничего не дает. Только если самому что-то писать (какие-то свои проверки) - тогда проверка нужна... Но тут и вопрос - если самому писать - то зачем тогда поддержка на уровне ядра?

Или я что-то не так понял?

Попутно присоединяюсь к вопросу автора ветки - почему запрещено-таки вызывать такие вещи, как сборка .NET, как ADO с сервера?

[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

[sukhanchik]

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

Цитата:

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

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

Ну, логично - что разрешение должно быть получено раньше, чем использован соотв. API. Понятно - что это является "синхронизацией" с .NET. Просто пока не могу в голове смоделировать контрпример, в каких случаях этот механизм разрешений именно защитит пользователя от исполнения "опасного" кода. Т.е. представим себе - что все вызовы "опасных" функций обрамляются в разрешения. Чем такой "обрамленный" код отличается от "необрамленного"? Только кол-вом кода, генерацией security cookie и т.д. Т.е. все равно кол-во "опасных" вызовов при этом не уменьшится. Не вижу предпосылок уменьшения использования "опасного" кода при этом программисту. Ну если нет аналога функции WinAPI::findWindow (к примеру) - а вызвать надо то хоть тресни - программисту придется ее вызвать - хоть с "обрамлением", хоть с бантиками, хоть завернутую в подарочную упаковку.

Цитата:

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

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

Об этом не подумал, спасибо. С этим согласен. В свое время в Access-е столкнулся с вызовом SQL-VBA-SQL и VBA-SQL-VBA - в этой конструкции Access просто вылетал с предложением послать все в MS.

Цитата:

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

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

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

Цитата:

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

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

.NET - рулит и все такое... Понятно...

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

нет разницы (в техническом плане) между исполнением кода на клиенте и на сервере. В обоих случаях посылается запрос на БД (мы ж не сравниваем исполнение кода на сервере БД и на клиенте).

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

Цитата:

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

Ккаким образом предполагается (предполагалось) контролировать - в каких условиях используется "опасное" API?

В примере защиты своего "опасного API" с помощью Code Access Security из Writing Secure X++ Code при запросе разрешения в конструктор класса-наследника CodeAccessPermission передаются некие данные, используемые затем для проверки наличия разрешения в ходе использования "опасного API". Так вот, этот пример, конечно, абстрактный, но, скажем, применительно к тому же FileIOPermission он уже обретает конкретику. Клиент API помимо типа разрешения еще и указывает, доступ какого рода и к какому именно ресурсу он хочет получить с помощью API. При этом "владелец" API может, скажем, по неким настройкам проверить, стоит ли давать доступ к этому ресурсу, например, можно ли пользователю, связанному с текущей сессией, давать доступ к тому или иному файлу на сервере от имени пользователя, под учетной записью которого работает AOS.

Цитата:

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

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

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

[sukhanchik]

В любом случае - очередной раз спасибо, gl00mie за потраченное время на разъяснение этого монстрового механизма.

[rkorchagin]

Вопрос: а perm.assert(); должен стоять перед каждым обращением к COM? Или хватает 1 раз в начале?

[belugin]

это зависит от того, вызывали ли вы revertAssert

[rkorchagin]

Можно ли одновременно вызвать ассерт для:

ExecutePermission
InteropPermission ?

Или кто из них главнее?