1. 22 Mar, 2019 2 commits
    • John Johansen's avatar
      dovecot: master SIGTERM child that are slow to die · 5014f4a9
      John Johansen authored
      When doing a service reload, I noticed the following:
      
      ```Mar 22 15:52:27 smtp dovecot: master: Warning: SIGHUP received - reloading configuration
      Mar 22 15:52:27 smtp dovecot: imap(simon): Server shutting down. in=35309 out=232805
      Mar 22 15:52:27 smtp dovecot: imap(simon): Server shutting down. in=24600 out=1688166
      Mar 22 15:52:27 smtp dovecot: imap(simon): Server shutting down. in=14026 out=95516
      Mar 22 15:52:27 smtp dovecot: imap(simon): Server shutting down. in=13776 out=141513
      Mar 22 15:52:33 smtp dovecot: master: Warning: Processes aren't dying after reload, sending SIGTERM.
      Mar 22 15:52:33 smtp dovecot: master: Error: service(imap): kill(5806, 15) failed: Permission denied
      Mar 22 15:52:33 smtp dovecot: master: Error: service(imap-login): kill(5804, 15) failed: Permission denied
      Mar 22 15:52:33 smtp dovecot: master: Error: service(config): kill(506, 15) failed: Permission denied
      Mar 22 15:52:33 smtp kernel: [65542.184326] audit: type=1400 audit(1553284353.609:82): apparmor="DENIED" operation="signal" profile="dovecot" pid=414 comm="dovecot" requested_mask="send" denied_mask="send" signal=term peer="/usr/lib/dovecot/imap"
      Mar 22 15:52:33 smtp kernel: [65542.197596] audit: type=1400 audit(1553284353.625:83): apparmor="DENIED" operation="signal" profile="dovecot" pid=414 comm="dovecot" requested_mask="send" denied_mask="send" signal=term peer="/usr/lib/dovecot/imap-login"
      Mar 22 15:52:33 smtp kernel: [65542.197635] audit: type=1400 audit(1553284353.625:84): apparmor="DENIED" operation="signal" profile="dovecot" pid=414 comm="dovecot" requested_mask="send" denied_mask="send" signal=term peer="/usr/lib/dovecot/config"
      Mar 22 15:52:36 smtp dovecot: imap(simon): Server shutting down. in=17882 out=104004
      ```
      
      The server was heavily loaded which is probably why it ended up trying to SIGTERM those.
      
      PR: !357Signed-off-by: 's avatarJohn Johansen <john.johansen@canonical.com>
      5014f4a9
    • Simon Deziel's avatar
      f01fd38c
  2. 21 Mar, 2019 3 commits
  3. 18 Mar, 2019 9 commits
  4. 16 Mar, 2019 1 commit
    • Christian Boltz's avatar
      update network keyword list in utils and add test · 49849ed7
      Christian Boltz authored
      The tools also have a list of network keywords, update it:
      - add xdp and qipcrtr
      - move ib and mpls to match the kernel order
      
      Also add a test to ensure that (at least) the keywords provided by the
      running kernel are listed in network_domain_keywords.
      49849ed7
  5. 15 Mar, 2019 2 commits
    • Christian Boltz's avatar
      remove_profiles(): Fix returning $retval · be02f008
      Christian Boltz authored
      Extend the subshell so that the actual (possibly non-zero) value of
      $retval gets returned. Before, the changed value was lost at "done"
      (= leaving the subshell), and the initial $retval=0 was returned.
      
      (found with shellcheck)
      be02f008
    • Christian Boltz's avatar
      drop most of apparmor_kill() · 0e3d6ee4
      Christian Boltz authored
      AppArmor can't be built as a kernel module since years, which also means
      it's impossible to unload it.
      0e3d6ee4
  6. 14 Mar, 2019 5 commits
  7. 13 Mar, 2019 6 commits
  8. 12 Mar, 2019 2 commits
    • John Johansen's avatar
    • John Johansen's avatar
      Merge branch 'xmatch_regex_priority' into 'master' · 2c4386a0
      John Johansen authored
      parser: determine xmatch priority based on smallest DFA match
      
      The length of a xmatch is used to prioritize multiple profiles that
      match the same path, with the intent that the more specific match wins.
      Currently, the length of a xmatch is computed by the position of the
      first regex character.
      
      While trying to work around issues with no_new_privs by combining
      profiles, we noticed that the xmatch length computation doesn't work as
      expected for multiple regexs. Consider the following two profiles:
      
          profile all /** { }
          profile bins /{,usr/,usr/local/}bin/** { }
      
      xmatch_len is currently computed as "1" for both profiles, even though
      "bins" is clearly more specific.
      
      When determining the length of a regex, compute the smallest possible
      match and use that for xmatch priority instead of the position of the
      first regex character.
      
      PR: !326Signed-off-by: 's avatarJohn Johansen <john.johansen@canonical.com>
      2c4386a0
  9. 11 Mar, 2019 3 commits
  10. 07 Mar, 2019 1 commit
  11. 26 Feb, 2019 2 commits
  12. 25 Feb, 2019 1 commit
  13. 24 Feb, 2019 1 commit
  14. 22 Feb, 2019 2 commits