Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 35

Хмм, идея интересная, были мысли сделать библиотеку на подобии такой.
Посмотрите мой топик про .NET компилятор. Так в принципе можно и не только эти языки сделать.
Также видел проект, рисующий графики функций, который компилит их «в уме».
Всего голосов 1: ↑1 и ↓0+1
Реализация подобного рода скриптования может быть опасной, поскольку из скриптов афайк может быть доступ к внутренним методам и данным приложения.
Всего голосов 3: ↑3 и ↓0+3
Об этом как раз сказано в заключении. Там же есть и решение — правильно настраивать уровни видимости — то, что к чему нельзя подпускать делаем internal. Правда защита такого плана обходится при помощи рефлексии. Сейчас как раз ищу способы защиты от такого.
Всего голосов 1: ↑1 и ↓0+1
Никак в управляемом коде. Тем более, не забывайте, что в код можно написать
Exec(«format»,«C:/ /F /R»); или что то в этом роде.
Хотя от такого можно защитить дописывая какой нибудь Namespace к функциям, но тогда придется копаться с переопределениями.
Кстати, можно еще права у кода поотбирать)
Всего голосов 1: ↑1 и ↓0+1
Скрипт можно запустить из отдельного домена с минимальным набором разрешений.
Всего голосов 1: ↑1 и ↓0+1
Можно. Но это .NET 4.0. Что накладывает некоторые ограничения.
Всего голосов 2: ↑1 и ↓10
Прошу прощения, AppDomain есть в любой версии .NET. То ли MSDN проглючило, то ли меня…
Всего голосов 2: ↑2 и ↓0+2
Скрипт нужно запускать в отдельном домене. Не только разрешения, но и стабильность выполнения.
Всего голосов 1: ↑1 и ↓0+1
Стабильность в каком смысле? Это ведь управляемый код.
Комментарий пока не оценивали0
Управляемый код, тем не менее, вполне может сожрать память, впасть в бесконечный цикл и предоставить прочие прелести программистских ошибок.

Отдельный апп-домен вы в любой момент можете выгрузить, даже если живущий в нем тред завис.
Комментарий пока не оценивали0
Не в любой момент, насколько я знаю. Если тред завис на выполнении неуправляемого кода или исполнении finally блока, домен выгрузить не удастся.

Код в другом AppDomain тоже может сожрать память. Хотя, если это контролировать, можно попробовать успеть его выгрузить.
Комментарий пока не оценивали0
«Если тред завис на выполнении неуправляемого кода или исполнении finally блока, домен выгрузить не удастся.»
А если завис ваш собственный тред, вы не можете его выгрузить никогда. И это большая разница.

Плюс Рихтер пишет (CLR via C#, 3rd Edition, глава Writing Robust Host Applications), что в четвертом фреймворке можно сделать escalation policy, который приведет к тому, что если домен нельзя положить «по правилам», его убьют без правил. И это еще один аргумент за отдельные домены.

«Код в другом AppDomain тоже может сожрать память.»
Тем не менее, контроля за ним у вас намного больше.
Комментарий пока не оценивали0
Согласен.
Комментарий пока не оценивали0
По поводу безопасности — могу дать несколько советов которые возможно вам помогут

1. Во первых класс «плагина» должен реализовывать ранее продуманный интерфейс. И этот класс должен предусматривать некий «менеджер» который будет отвечать за доступ к важным данным и функциям основного приложения.

2. Доступ к файлику с паролями стоит ограничить. Как минимум приложение может его просто блокировать в начале работы и разблокировать после выгрузки «плагинов» (вариант грубый но простой)

3. Если есть критические данные в базе — то не давать доступа к connection string а опять же работать через менеджер которые дает возможность реализовать безопасный доступ к данным и контролировать операции из основного приложения.

4. Ну и еще есть вариант подписи плагинов — то есть прежде чем плагин выпустить в свободное плавание — его исходный код изучает специалист и проверяет на потенциально опасный код. Такая система например с приложения в App Store от Apple. (Хотя опять же зависит от конкретной ситуации — подходит такой вариант, или нет)
Всего голосов 5: ↑5 и ↓0+5
1. Во первых класс «плагина» должен реализовывать ранее продуманный интерфейс. И этот класс должен предусматривать некий «менеджер» который будет отвечать за доступ к важным данным и функциям основного приложения.


2. Доступ к файлику с паролями стоит ограничить. Как минимум приложение может его просто блокировать в начале работы и разблокировать после выгрузки «плагинов» (вариант грубый но простой)


Всего голосов 1: ↑1 и ↓0+1
Предыдущий комент почему-то самопроизвольно отправился…

1. Во первых класс «плагина» должен реализовывать ранее продуманный интерфейс. И этот класс должен предусматривать некий «менеджер» который будет отвечать за доступ к важным данным и функциям основного приложения.

Как раз такого подхода я и хочу добиться. Здесь проблема в том, что надо запретить в коде сточки вида System.IO.FileStream file = new System.IO.FileStream(«путь_до_важного_файла_с_паролями»);

2. Доступ к файлику с паролями стоит ограничить. Как минимум приложение может его просто блокировать в начале работы и разблокировать после выгрузки «плагинов» (вариант грубый но простой)

В статье я имел в виду файлы паролей не только самого приложения. Например — файл %APPDATA%/Opera/Opera/wand.dat. Не очень хорошо будет если такой файл попадёт не в те руки.

4. Ну и еще есть вариант подписи плагинов — то есть прежде чем плагин выпустить в свободное плавание — его исходный код изучает специалист и проверяет на потенциально опасный код. Такая система например с приложения в App Store от Apple. (Хотя опять же зависит от конкретной ситуации — подходит такой вариант, или нет)

К сожалению в моём случае не подходит.
Всего голосов 1: ↑1 и ↓0+1
«Как раз такого подхода я и хочу добиться. Здесь проблема в том, что надо запретить в коде сточки вида System.IO.FileStream file = new System.IO.FileStream(«путь_до_важного_файла_с_паролями»);»
Ну так отнять у выполняемого кода FilePermission, и все.
Всего голосов 1: ↑1 и ↓0+1
Внезапно в топик врывается кодогенерация через System.Linq.Expressions и DLR, который для реализации скриптов и придумали (см. IronPython, IronRuby и прочее).

Сразу, чтобы отмести обвинения в .net 4-only, DLR изначально был реализован в виде отдельной библиотеки — dlr.codeplex.com/
В Mono работает.

А System.CodeDom.Compiler изначально был нужен для кодогенерации именно в компиляторах.

Давайте все-таки использовать инструменты по назначению.
Всего голосов 6: ↑6 и ↓0+6
В целом верно. Сам зашел в этот пост чтобы проверить, предложено ли это очевидное (для меня) решение.
А что вы можете добавить по ограничению прав такого скрипта?
Всего голосов 1: ↑1 и ↓0+1
В документации предлагается запускать скрипты из отдельного аппдомена, как было уже предложено выше.
Комментарий пока не оценивали0
Кроме того, почти все классы из System.CodeDom.Compiler недоступны в Silverlight, например.
Всего голосов 1: ↑1 и ↓0+1
Спасибо за ещё одно направление в котором нужно подумать. До этого так нормально и не знал для чего предназначен DLR. Сейчас посмотрел его поверхностно — позже посмотрю поподробнее. Однако мне кажется что любой подход имеет право на существование — в качестве плюсов к моему методу могу сказать что у меня уже сразу используется готовый язык. В случае DLR же, если я правильно понял, надо ещё описать синтаксис языка, и что во что компилируется.
Всего голосов 2: ↑2 и ↓0+2
Да, во времена, когда еще существовал Managed DirectX, Майкрософт предлагал подход аналогичный вашему для скриптования игрушек.
Комментарий пока не оценивали0
У моно есть же специальное безопасное решение для создания песочниц с поддержкой CoreCLR и прочего. Они на его основе безопасность в мунлайте делали.
Всего голосов 1: ↑1 и ↓0+1
Хм. Интересно. А где можно поподробнее посмотреть как это можно использовать у себя? А то на сайте mono нашёл только два страничке посвященные песочнице Mono.
Всего голосов 1: ↑1 и ↓0+1
Если я правильно понял — это решение чисто для Mono. Там все классы помечаются как безопасные и небезопасные…
Всего голосов 1: ↑1 и ↓0+1
> я мог править код, на лету перекомпилируя его прямо в своём приложении

Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Всего голосов 1: ↑0 и ↓1-1
посмотрите на Boo — его вроде как немного забросили, но он позволяет делать и более сложные штуки без такого шаманства.
Всего голосов 2: ↑1 и ↓10
Немного не в тему, но какие библиотеки Вы использовали для работы с Lua? Я пару лет назад использовал LuaInterface, было очень удобно. Никакой кучи биндингов. Правда я не уверен на счёт его работы с моно.
Комментарий пока не оценивали0
Честно говоря уже не помню что я рассматривал. Но вроде был и LuaInterface который меня тоже чем-то не устроил.
Комментарий пока не оценивали0
Кстати, если не ошибаюсь, сгенерированный раз код так и остается висеть в памяти, поскольку отдельную сборку в .NET выгрузить нельзя. Только AppDomain целиком. Так что домен все равно желательно создавать. Но тогда доступ к функциям сборки будет несколько затруднен?
Комментарий пока не оценивали0
Я честно говоря думал что сборка автоматом выгрузится сборщиком мусора. А по поводу затруднения доступа — есть такое. Если я правильно понял — то из домена можно либо запустить на выполнение exe, либо создать экземпляр какого либо объекта и уже с ним работать. Если я правильно понял — то просто вызвать статический метод — нельзя (если он не является точкой входа)
Комментарий пока не оценивали0
«Я честно говоря думал что сборка автоматом выгрузится сборщиком мусора.»
Зря вы так думали. .net framework не умеет выгружать отдельные сборки из домена, только домен целиком.

«Если я правильно понял — то из домена можно либо запустить на выполнение exe, либо создать экземпляр какого либо объекта и уже с ним работать. Если я правильно понял — то просто вызвать статический метод — нельзя (если он не является точкой входа) „
Это-то мелочи. В реальности вы вообще (к счастью) не можете протащить через границу домена ни один объект, не попадающий под определенные ограничения.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr