|
|
#17 |
|
Administrator
|
Цитата:
Сообщение от gl00mie
Здесь принципиально то, что контроль над использованием опасных API выносится с уровня приложения на уровень ядра и становится, таким образом, доступен пользователю (администратору). Так, к примеру, на уровень "ядра" вынесены различные настройки параметров безопасности MSIE, и можно вручную или групповыми политиками настроить, что делать можно, а чего нельзя, не ковыряясь в каждом отдельном сайте, страничке или Java-скрипте. Аналогично, может быть, в будущих версиях Аксапты можно будет настраивать на уровне конфигурационной утилиты, какие именно "опасные API" можно использовать, к каким ресурсам и какого рода доступ можно предоставлять с их помощью.
Цитата:
Сообщение от gl00mie
Я тут подумал, что все же разница есть - именно применительно к разрешениям Предположим, что код приложения должен обратиться к какому-то файлу - для этого он запрашивает FileIOPermission с указанием, к какому именно файлу и в каком режиме (чтение, запись, добавление) код хочет обратиться. Если бы можно было получить разрешение на клиенте, а использовать его на сервере, то получилось бы, что проверка прошла бы для одного объекта (файла по тому пути, как он видится с машины клиента), а реальный доступ был бы осуществлен в общем случае к совершенно другому объекту (файлу по тому пути, как он видится на сервере, даже если это в точности такой же путь, что и на клиенте). Очевидно, такой ситуации допускать нельзя: к какому объекту запросили (и получили) разрешение на доступ, к тому и применяйте это разрешение. Отсюда, видимо, и ограничение, касающееся использования разрешения на том же уровне (на клиенте либо на сервере), на каком оно было получено.Цитата:
![]() Просто у меня отношение к защите и безопасности - такое: Защита некоего действия не должна это действие отменять или запрещать. Т.е. бессмысленно в рамках охраны человека его убивать, дабы это не сделали другие. Бессмысленно в рамках защиты сервера полностью отключать к нему доступ. Бессмысленно в рамках поддержки делать такую бюрократическую проволочку - что от момента заявки пользователя (в случае, если это останавливает его работу) до момента устранения заявки проходит такое кол-во времени, что ставит под сомнение необходимость его работы в системе. Применительно к Аксапте - могу сказать - что каковы бы не были благородные намерения защищающих - но если в результате защиты нарушается принцип работы "вся работа с БД осуществляется на сервере" и работа сервера переносится на клиента - то в этом случае либо не нужна такая система, либо не нужна такая защита (в определенном смысле это же увеличивает стоимость владения системой - нужен новый комп, возможно и требуется обновление сетевого оборудования).
__________________
Возможно сделать все. Вопрос времени |
|
|
| Теги |
| .net, cas, code access security, fileiopermission, interoppermission, security, безопасность |
|
|
|