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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1749389

Title:
  ntpdate lock apparmor deny

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to