OberonCore

Если остановиться на приватных для подсистемы модулях, то их можно выделять особыми именами (суффикс, префикс...)

Тогда обёртка StdLoader или он сам изменённый отказывается грузить модуль из подсистемы A, если видит в списке его импорта приватный модуль другой подсистемы.

Вроде просто... Но не стандартный StdLoader, не применить к модулям ББ.

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

Понятия первичны, реализации вторичны.

Как указал igor ИМХО, все модули равны, и нет среди них таких, которые равнее.

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

Например,
делим пользователей на 3 класса:
1) системные программисты;
2) прикладные программисты;
3) конечные пользователи.

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

Тогда ограниченный импорт есть разница в доступе между первыми двумя видами.
Ну а регулирование доступа...
1. Вставки в язык - плохо - таким путем уже пошли дельфи/жабы/сишарпы. Появилось много лишних буков.
2. Хитрая пряталка, как сказывал Димыч, - плохо - в Дельфи закрыли ВСЕ поля и наплодили свойств, чем и хвастались, что есть лишние сущности.
3. В стиле ББ - разнести по каталогам и задать в инструментах два режима по штуке каждой категории.

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

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

В общем, поддерживаю.

А про "умолчания" - так в DEFINITION сейчас, например, не включаются типы и процедуры, в которых фигурируют расширения Kernel.Hook.

То есть логиниться при входе в систему?

Перечитал всю тему еще раз и задался вопросом, а оно вообще надо?

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

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

Вволю намучавшись с *.so файлом и Kernel, прихожу к выводу, что надо переписывать DevElfLinker, чтобы исключить танцы, бубен и завывания не только с ограниченным импортом, но и со многим другим.

Только вот не знаю, дойдут ли руки?

Ну вот как-то так…
P.S. ABI мне в помощь

Нет. Речь идет о том, что себе вы оставляете систему с полным доступом, а поставляете для пользователей систему с меньшими возможностями "сломать".

У меня сложилось мнение, что решать проблему защиты от преднамеренного разрушения в рамках языковых средств не стоит. Хорошо это сделать не удастся, а если успорствовать, то можно потерять многие простые и эффективные схемы работы. (Вот если мы начнём думать - а что будет, если кто-то перепишет какой-нибудь dir.. И т.п.)

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

А "от дураков" - лучше просто иметь возможность дать каждому дураку свою копию на растерзание Если развить эту схему... То много чего интересного в голову лезет

Со всем можно согласиться, если "безопасность" и производные заменить соответственно на "надёжность". А пароли и удаление интерфейсов это одновременно внеязыковое средство и размышления на тему именно безпасности. : )

Оказалось, что тема ограниченного импорта уже обсуждалась 2 года назад. Для полноты даю ссылку
http://forum.oberoncore.ru/viewtopic.php?f=2&t=489