Skip to content
Snippets Groups Projects
  1. Oct 29, 2020
  2. Sep 18, 2020
  3. May 15, 2020
    • Markus Armbruster's avatar
      qom: Drop parameter @errp of object_property_add() & friends · d2623129
      Markus Armbruster authored
      
      The only way object_property_add() can fail is when a property with
      the same name already exists.  Since our property names are all
      hardcoded, failure is a programming error, and the appropriate way to
      handle it is passing &error_abort.
      
      Same for its variants, except for object_property_add_child(), which
      additionally fails when the child already has a parent.  Parentage is
      also under program control, so this is a programming error, too.
      
      We have a bit over 500 callers.  Almost half of them pass
      &error_abort, slightly fewer ignore errors, one test case handles
      errors, and the remaining few callers pass them to their own callers.
      
      The previous few commits demonstrated once again that ignoring
      programming errors is a bad idea.
      
      Of the few ones that pass on errors, several violate the Error API.
      The Error ** argument must be NULL, &error_abort, &error_fatal, or a
      pointer to a variable containing NULL.  Passing an argument of the
      latter kind twice without clearing it in between is wrong: if the
      first call sets an error, it no longer points to NULL for the second
      call.  ich9_pm_add_properties(), sparc32_ledma_realize(),
      sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize()
      are wrong that way.
      
      When the one appropriate choice of argument is &error_abort, letting
      users pick the argument is a bad idea.
      
      Drop parameter @errp and assert the preconditions instead.
      
      There's one exception to "duplicate property name is a programming
      error": the way object_property_add() implements the magic (and
      undocumented) "automatic arrayification".  Don't drop @errp there.
      Instead, rename object_property_add() to object_property_try_add(),
      and add the obvious wrapper object_property_add().
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Message-Id: <20200505152926.18877-15-armbru@redhat.com>
      [Two semantic rebase conflicts resolved]
      d2623129
  4. Jun 12, 2019
  5. May 13, 2019
  6. Feb 26, 2019
    • Daniel P. Berrangé's avatar
      authz: add QAuthZList object type for an access control list · c8c99887
      Daniel P. Berrangé authored
      
      Add a QAuthZList object type that implements the QAuthZ interface. This
      built-in implementation maintains a trivial access control list with a
      sequence of match rules and a final default policy. This replicates the
      functionality currently provided by the qemu_acl module.
      
      To create an instance of this object via the QMP monitor, the syntax
      used would be:
      
        {
          "execute": "object-add",
          "arguments": {
            "qom-type": "authz-list",
            "id": "authz0",
            "props": {
              "rules": [
                 { "match": "fred", "policy": "allow", "format": "exact" },
                 { "match": "bob", "policy": "allow", "format": "exact" },
                 { "match": "danb", "policy": "deny", "format": "glob" },
                 { "match": "dan*", "policy": "allow", "format": "exact" },
              ],
              "policy": "deny"
            }
          }
        }
      
      This sets up an authorization rule that allows 'fred', 'bob' and anyone
      whose name starts with 'dan', except for 'danb'. Everyone unmatched is
      denied.
      
      It is not currently possible to create this via -object, since there is
      no syntax supported to specify non-scalar properties for objects. This
      is likely to be addressed by later support for using JSON with -object,
      or an equivalent approach.
      
      In any case the future "authz-listfile" object can be used from the
      CLI and is likely a better choice, as it allows the ACL to be refreshed
      automatically on change.
      
      Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
      Tested-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
      Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
      c8c99887
Loading