Кратко

  • Правила смонтированной модели могут учитывать выбранные данные родителя. Изменение этого выбора способно повлиять на зависимое ограничение без изменения модуля.
  • parent-reference расширяет контекст вычисления XPath, но сам по себе не открывает выбранные родительские узлы для чтения или записи через смонтированное дерево.
  • Общая схема не означает одинаковые данные, а граница путей не доказывает изоляцию пользователей. Ответственность за композицию должна быть отделена от ответственности за определения модуля.

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

YANG Schema Mount даёт конкретный пример такой зависимости. Механизм позволяет размещать целые готовые модели под точками, определёнными в родительской модели. Не нужно заранее переписывать каждый модуль под все возможные внешние структуры. Отношение между моделями задаётся за пределами смонтированных модулей, что делает повторное использование практичнее.

Однако граница исходного файла не становится границей эксплуатационного поведения. Если ограничение использует сведения, выбранные у родителя, объяснять результат придётся с учётом этой связи. Вопрос состоит не в том, кто последним изменял модуль, а в том, кто управляет значимым для него окружением.

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

Начать расследование с правильного объекта

В приложении A.3 к RFC 8528 приведён пример сетевой инстанции. Выражение выбирает интерфейсы родительской модели по их привязке к текущей инстанции. Смонтированная модель благодаря этому может ссылаться на выходной интерфейс статического маршрута, хотя модуль интерфейсов не входит в её собственную схему.

Это означает, что вопрос «есть ли такой интерфейс на устройстве?» может оказаться слишком широким. Для конкретной зависимости нужно понять, входит ли интерфейс в выбранное множество. Наличие в общем перечне ещё не объясняет его роль в данной инстанции. Один и тот же способ выбора, применённый из разных контекстов, может дать разные результаты.

Пример не нормативный и не является подтверждением совместимости изделия. Его полезность в другом: он показывает отношение, которое легко потерять при передаче модели между командами. Определения остаются в одном месте, а назначение объектов, на которые они опираются, может находиться в другом.

Поэтому пакет для расследования должен содержать не только модуль и кандидат конфигурации. Нужна та часть родительского контекста, которая объясняет спорную ссылку. Без неё можно многократно подтвердить неизменность файлов и ни разу не проверить гипотезу, действительно относящуюся к результату.

Какая именно зависимость проверяется

Язык YANG задаёт ограничения must, которые должны быть истинными для соответствующих данных. Для ссылок на листья существенна настройка require-instance: при true требуется соответствующий экземпляр согласно правилам языка, при false его отсутствие может допускаться. У значений по умолчанию и ссылок между конфигурационными данными есть дополнительные условия. Они описаны в RFC 7950.

Обобщение «любая ссылка обязана указывать на существующий объект» поэтому недостаточно точно. Сначала надо установить вид ссылки, её условия и дерево, относительно которого она оценивается. Только после этого имеет смысл обсуждать, какие внешние изменения могли повлиять на ответ.

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

Не всякая правка родителя влияет на все ограничения. Изменённый узел может не участвовать в выборе; множество может остаться тем же; конкретное правило может вообще не обращаться к добавленным данным. Полезное расследование прослеживает отдельную зависимость, а не объявляет любое изменение окружения причиной по умолчанию.

Точность нужна и при чтении стандартных примеров. Проверенное редакционное исправление 5797 касается другой части приложения: поле привязки интерфейса к логическому сетевому элементу должно содержать имя элемента, а не имя самого интерфейса. Оно не отменяет механизм родительских ссылок. Исправление лишь напоминает, что два правдоподобных идентификатора могут обозначать разные типы объектов.

Видимость при вычислении не передаёт управление

Обычные пути внутри смонтированной модели отсчитываются от точки монтирования. Корень всего устройства не становится их корнем автоматически. В режиме общей схемы parent-reference предоставляет явный способ добавить выбранные родительские данные в контекст XPath.

Выражения вычисляются в родительском контексте и возвращают множества узлов. Их объединение вместе с предками добавляется к дереву, доступному для XPath в смонтированной модели. Так нижележащие правила получают возможность учитывать определённые сведения извне.

При этом выбранные узлы не становятся доступными для операций NETCONF или RESTCONF через смонтированное дерево. Правило может учитывать назначение интерфейса, но пользователь модели не получает из этого факта право читать или менять само назначение. Слово «доступ» скрывает здесь два разных отношения: участие данных в вычислении и полномочие клиента на действие.

Различие полезно само по себе. Оно позволяет модели зависеть от централизованно поддерживаемой информации, не передавая всем её пользователям административный контроль. Но именно поэтому описание одних только пользовательских прав не исчерпывает список зависимостей, влияющих на проверку конфигурации.

Термин mount jail также нельзя читать как обещание полноценной изоляции арендаторов или процессов. Речь прежде всего о трактовке путей модели. Название механизма не доказывает разделение вычислительных ресурсов и не заменяет оценку реальных сеансов и разрешений.

Что показывает сервер, а что остаётся за описанием

Точки монтирования задаются родительской моделью в контейнерах или списках. Операционные данные schema-mounts описывают предоставляемую сервером композицию. Но из наличия этого дерева не следует, что оно является универсальным записываемым интерфейсом для изменения всех сочетаний моделей.

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

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

В режиме общей схемы инстанции одной точки монтирования используют одинаковую схему. Inline допускает разные схемы. Каждая операционная инстанция предоставляет YANG Library, но совпадение идентификаторов содержимого у двух inline-инстанций не гарантирует равенства их библиотек. На это прямо указывает RFC 8528.

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

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

Три вопроса вместо одного статуса

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

Если реализован NACM, контроль доступа применяется к смонтированным узлам по их положению в составном дереве. Точка монтирования не создаёт автоматически независимую частную систему полномочий. Варианты общего и разделённого управления описывают организацию сеансов, а не все свойства безопасности.

RFC 8341 о NACM предупреждает также о зависимостях модели, ссылках и неявных эффектах. Отказ в прямом чтении не полностью описывает, какие сведения пользователь может вывести из связанных данных или разрешённых операций. Это общая оговорка о безопасности, а не доказательство конкретной атаки на Schema Mount.

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

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