ntpdate lock apparmor deny
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ntp (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Xenial |
Fix Released
|
Medium
|
Unassigned | ||
Artful |
Fix Released
|
Medium
|
Unassigned |
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=
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=
The rule we need is:
/run/lock/ntpdate wk,
Note: When we open up a SRU for ntp apparmor we should include the minot (bot on its own not SRu worthy) fix of bug 1741227