DDS-SECURITY 1.2 RTF Avatar
  1. OMG Issue

DDSSEC12 — Built-in Access Control: interpretation of enable_read/write_access_control

  • Key: DDSSEC12-79
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The check_create_participant entry of "Table 63 - Actions undertaken..." in the case where is_access_protected is true and all topic entries in Governance have enable_read_access_control and enable_write_access_control both true specifies that check_create_participant returns false. Thus the participant can't be created and this configuration won't be usable.

    If the intent of enable_read/write_access_control is to defer to the Permissions document to determine both readability and write-ability of this participant (for the given topic) it would seem like this case should be supported and allowed by check_create_participant.

    As part of resolving this issue we should also address DDSSEC12-85, meaning state whether a <default> clause should always be present.

  • Reported: DDS-SECURITY 1.1 — Fri, 16 Nov 2018 23:24 GMT
  • Disposition: Resolved — DDS-SECURITY 1.2
  • Disposition Summary:

    Clarify interpretation of enable_read/write_access_control

    Clarify behavior as suggested in issue description

  • Updated: Mon, 17 Jun 2024 13:36 GMT