3.2.4. RTI Security Plugins¶
The following issue affects backward compatibility in RTI Security Plugins when migrating from Release 6.1.0 to Release 6.1.1.
22.214.171.124. Problems checking whether a participant is allowed to exist¶
In Connext 6.1.0 and below, if a Permissions Document contained conflicting allow and deny rules for a given domain combination, then the rule that took effect when creating or discovering new DomainParticipants was the rule that appeared last in the document. This order of precedence is not the intention of the DDS Security specification. In this release, the rule that takes effect by default is the one that appears first in the document.
For example, in previous Connext versions, in the following Permissions Document snippet, a DomainParticipant on domain 12 was incorrectly allowed to be created:
<deny_rule> <domains> <id>12</id> </domains> </deny_rule> <allow_rule> <domains> <id>12</id> </domains> </allow_rule>
This problem has been fixed in release 6.1.1. Now, the first rule will be applied, so a DomainParticipant on domain 12 will fail to be created.
In general, to avoid the question of precedence, we recommend, if possible, rewriting your Permissions Document to eliminate conflicting rules.
To keep backwards compatibility with existing Connext 6.1.0 DomainParticipants
that cannot update their Permissions Document, release 6.1.1 will, by default,
automatically apply the preference order based on the version of the DomainParticipant
associated with the Permissions Document. This behavior can be changed through
property, which supports the following values:
auto (default): use the last applicable rule if the DomainParticipant’s version is known to use the last applicable rule (e.g., for release 6.1.0 or below), and use the first applicable rule otherwise.
false: always use the first applicable rule.
true: always use the last applicable rule.
Note that the default behavior may change in future releases of Connext.