Bionic - ok
SRU Template - ok
Debdiff for X/T checked - ok
Tested X/A upload from ppa - ok.

I Identified another issue in the log as bug 1670408 which needs a fix in 
apparmor - not ntp.
That means this is ok to be uploaded (not gated by that finding).

** Description changed:

  [Impact]
  
-  * Apparmor denies access to lock it shares with ntpdate to ensure no 
-    issues due to concurrent access
+  * Apparmor denies access to lock it shares with ntpdate to ensure no
+    issues due to concurrent access
  
  [Test Case]
  
-  1. get a container of target release
-  2. install ntp
-     apt install ntp
-  3. watch dmesg on container-host
-     dmesg -w 
-  4. restart ntp in container
-     systemctl restart ntp
-  => see (or no more after fix) apparmor denie:
-     apparmor="DENIED" operation="file_inherit" profile="/usr/sbin/ntpd" 
name="/run/lock/ntpdate" pid=30113 comm="ntpd" requested_mask="w" 
denied_mask="w"
+  1. get a container of target release
+  2. install ntp
+     apt install ntp
+  3. watch dmesg on container-host
+     dmesg -w
+  4. restart ntp in container
+     systemctl restart ntp
+  => see (or no more after fix) apparmor denie:
+     apparmor="DENIED" operation="file_inherit" profile="/usr/sbin/ntpd" 
name="/run/lock/ntpdate" pid=30113 comm="ntpd" requested_mask="w" 
denied_mask="w"
+     Note: to not be mislead, on xenial there is a remaining stdout appamor 
+     issue which is bug 1670408
  
  [Regression Potential]
  
-  * we are only slightly opening up the apparmor profile, but none of the 
-    changes poses a security risk so regression potential on it's own 
-    should be close to zero.
+  * we are only slightly opening up the apparmor profile, but none of the
+    changes poses a security risk so regression potential on it's own
+    should be close to zero.
  
-  * There is a potential issue if the locking (that now can succeed) would 
-    e.g. no more be freed up or the action behind the locking would cause 
-    issues.
+  * There is a potential issue if the locking (that now can succeed) would
+    e.g. no more be freed up or the action behind the locking would cause
+    issues.
  
  [Other Info]
-  
-  * n/a
  
+  * n/a
  
- On start/restart nto has an error in apparmor due to the locking it tries to 
avoid issues running concurrently with ntpdate.
+ On start/restart nto has an error in apparmor due to the locking it
+ tries to avoid issues running concurrently with ntpdate.
  
  That looks like:
  apparmor="DENIED" operation="file_inherit" profile="/usr/sbin/ntpd" 
name="/run/lock/ntpdate" pid=30113 comm="ntpd" requested_mask="w" 
denied_mask="w"
  
  The rule we need is:
  /run/lock/ntpdate wk,

** Changed in: ntp (Ubuntu Xenial)
       Status: Triaged => In Progress

** Changed in: ntp (Ubuntu Artful)
       Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1749389

Title:
  ntpdate lock apparmor deny

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Fix Committed
Status in ntp source package in Artful:
  Fix Committed

Bug description:
  [Impact]

   * Apparmor denies access to lock it shares with ntpdate to ensure no
     issues due to concurrent access

  [Test Case]

   1. get a container of target release
   2. install ntp
      apt install ntp
   3. watch dmesg on container-host
      dmesg -w
   4. restart ntp in container
      systemctl restart ntp
   => see (or no more after fix) apparmor denie:
      apparmor="DENIED" operation="file_inherit" profile="/usr/sbin/ntpd" 
name="/run/lock/ntpdate" pid=30113 comm="ntpd" requested_mask="w" 
denied_mask="w"
      Note: to not be mislead, on xenial there is a remaining stdout appamor 
      issue which is bug 1670408

  [Regression Potential]

   * we are only slightly opening up the apparmor profile, but none of the
     changes poses a security risk so regression potential on it's own
     should be close to zero.

   * There is a potential issue if the locking (that now can succeed) would
     e.g. no more be freed up or the action behind the locking would cause
     issues.

  [Other Info]

   * n/a

  On start/restart nto has an error in apparmor due to the locking it
  tries to avoid issues running concurrently with ntpdate.

  That looks like:
  apparmor="DENIED" operation="file_inherit" profile="/usr/sbin/ntpd" 
name="/run/lock/ntpdate" pid=30113 comm="ntpd" requested_mask="w" 
denied_mask="w"

  The rule we need is:
  /run/lock/ntpdate wk,

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1749389/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to