1. 22 8月, 2019 3 次提交
  2. 21 8月, 2019 22 次提交
  3. 20 8月, 2019 12 次提交
  4. 19 8月, 2019 3 次提交
    • A
      virt-aa-helper: Fix AppArmor profile · b1eb8b3e
      Andrea Bolognani 提交于
      Since
      
        commit 432faf25
        Author: Michal Privoznik <mprivozn@redhat.com>
        Date:   Tue Jul 2 19:49:51 2019 +0200
      
          virCommand: use procfs to learn opened FDs
      
          When spawning a child process, between fork() and exec() we close
          all file descriptors and keep only those the caller wants us to
          pass onto the child. The problem is how we do that. Currently, we
          get the limit of opened files and then iterate through each one
          of them and either close() it or make it survive exec(). This
          approach is suboptimal (although, not that much in default
          configurations where the limit is pretty low - 1024). We have
          /proc where we can learn what FDs we hold open and thus we can
          selectively close only those.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      
        v5.5.0-173-g432faf25
      
      programs using the virCommand APIs on Linux need read access to
      /proc/self/fd, or they will fail like
      
        error : virCommandWait:2796 : internal error: Child process
        (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c
         -u libvirt-b20e9a8e-091a-45e0-8823-537119e98bc6) unexpected exit
        status 1: libvirt:  error : cannot open directory '/proc/self/fd':
        Permission denied
        virt-aa-helper: error: apparmor_parser exited with error
      
      Update the AppArmor profile for virt-aa-helper so that read access
      to the relevant path is granted.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      b1eb8b3e
    • A
      virt-aa-helper: Call virCommandRawStatus() · b194c3d9
      Andrea Bolognani 提交于
      The way we're processing the return status, using WIFEXITED() and
      friends, only works when we have the raw return status; however,
      virCommand defaults to processing the return status for us. Call
      virCommandRawStatus() before virCommandRun() so that we get the raw
      return status and the logic can actually work.
      
      This results in guest startup failures caused by AppArmor issues
      being reported much earlier: for example, if virt-aa-helper exits
      with an error we're now reporting
      
        error: internal error: cannot load AppArmor profile 'libvirt-b20e9a8e-091a-45e0-8823-537119e98bc6'
      
      instead of the misleading
      
        error: internal error: Process exited prior to exec: libvirt:
        error : unable to set AppArmor profile 'libvirt-b20e9a8e-091a-45e0-8823-537119e98bc6'
        for '/usr/bin/qemu-system-x86_64': No such file or directory
      Suggested-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      b194c3d9
    • A
      virt-aa-helper: Use virCommand APIs directly · 7d3a0f56
      Andrea Bolognani 提交于
      Right now we're using the virRun() convenience API, but that
      doesn't allow the kind of control we want. Use the virCommand
      APIs directly instead.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      7d3a0f56