From: Stefan Bader <stefan.bader@canonical.com>
Prevent denial messages related to attempted reads on lttng
files from spamming the logs.
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1432644
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
examples/apparmor/libvirt-qemu | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu
index 77c72a5..651d841 100644
--- a/examples/apparmor/libvirt-qemu
+++ b/examples/apparmor/libvirt-qemu
@@ -191,3 +191,7 @@
/sys/devices/system/node/ r,
/sys/devices/system/node/node[0-9]*/meminfo r,
/sys/module/vhost/parameters/max_mem_regions r,
+
+ # silence refusals to open lttng files (see LP: #1432644)
+ deny /dev/shm/lttng-ust-wait-* r,
+ deny /run/shm/lttng-ust-wait-* r,
--
2.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2017-12-19 at 16:03 +0100, Christian Ehrhardt wrote: > From: Stefan Bader <stefan.bader@canonical.com> > > Prevent denial messages related to attempted reads on lttng > files from spamming the logs. > > Bug-Ubuntu: https://bugs.launchpad.net/bugs/1432644 > > Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> > Signed-off-by: Stefan Bader <stefan.bader@canonical.com> > --- > examples/apparmor/libvirt-qemu | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/examples/apparmor/libvirt-qemu > b/examples/apparmor/libvirt-qemu > index 77c72a5..651d841 100644 > --- a/examples/apparmor/libvirt-qemu > +++ b/examples/apparmor/libvirt-qemu > @@ -191,3 +191,7 @@ > /sys/devices/system/node/ r, > /sys/devices/system/node/node[0-9]*/meminfo r, > /sys/module/vhost/parameters/max_mem_regions r, > + > + # silence refusals to open lttng files (see LP: #1432644) > + deny /dev/shm/lttng-ust-wait-* r, > + deny /run/shm/lttng-ust-wait-* r, +1 to apply. These are noisy and not needed by typical guests. -- Jamie Strandboge | http://www.canonical.com-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Hi, Christian Ehrhardt: > --- a/examples/apparmor/libvirt-qemu > +++ b/examples/apparmor/libvirt-qemu > @@ -191,3 +191,7 @@ > /sys/devices/system/node/ r, > /sys/devices/system/node/node[0-9]*/meminfo r, > /sys/module/vhost/parameters/max_mem_regions r, > + > + # silence refusals to open lttng files (see LP: #1432644) > + deny /dev/shm/lttng-ust-wait-* r, > + deny /run/shm/lttng-ust-wait-* r, In principle this looks OK to me but I wonder if this is the sweet spot regarding admin UX. I've skimmed over the Ubuntu bug report but found it confusing as it mixes breakage caused by the fact we deny such access (which apparently does not happen anymore otherwise you would not be proposing these deny rules) with log flooding issues (that will be fixed by the proposed rules). So I'm afraid I need to ask an executive summary :) Under which circumstances do we log these denials? I'd like to make sure we're not creating the following situation: - In most practical cases we don't even try to access these files, so don't log denials, and then these rules are not useful. - In the rare(r) case when the admin actually enables LTT-ng debugging, with these added rules it'll be hard to discover why it does not work. Thanks in advance! Cheers, -- intrigeri -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Dec 20, 2017 at 10:30 AM, intrigeri <intrigeri+libvirt@boum.org> wrote: > Hi, > > Christian Ehrhardt: >> --- a/examples/apparmor/libvirt-qemu >> +++ b/examples/apparmor/libvirt-qemu >> @@ -191,3 +191,7 @@ >> /sys/devices/system/node/ r, >> /sys/devices/system/node/node[0-9]*/meminfo r, >> /sys/module/vhost/parameters/max_mem_regions r, >> + >> + # silence refusals to open lttng files (see LP: #1432644) >> + deny /dev/shm/lttng-ust-wait-* r, >> + deny /run/shm/lttng-ust-wait-* r, > > In principle this looks OK to me but I wonder if this is the sweet > spot regarding admin UX. > > I've skimmed over the Ubuntu bug report but found it confusing as it > mixes breakage caused by the fact we deny such access (which > apparently does not happen anymore otherwise you would not be > proposing these deny rules) with log flooding issues (that will be > fixed by the proposed rules). > > So I'm afraid I need to ask an executive summary :) > Under which circumstances do we log these denials? > > I'd like to make sure we're not creating the following situation: > > - In most practical cases we don't even try to access these files, so > don't log denials, and then these rules are not useful. > > - In the rare(r) case when the admin actually enables LTT-ng > debugging, with these added rules it'll be hard to discover why it > does not work. Great point intrigeri! #1 At least as far as my history analysis went this was triggered by ceph having the support for lttng enabled. Not by actually (trying to) enable the LTT-ng tracking. While being disabled in ceph package since then it could show up in a similar manner from almost any other source. #2 OTOH I never have seen any complains on LTT-ng not working in the virt stack for the years carrying this delta. So either it is not an issue to those using LTT-ng or no one (statistically) uses it on virt-hosts in a case that would require it to get these access. Especially due to #1 IMHO I'd tend to add the denies as the flooding hits people not explicitly enabling/caring about LTT-ng. It would be great if instead of allow/deny we had the option to "deny but report once" - like a ratelimit, but we don't. > Thanks in advance! > > Cheers, > -- > intrigeri -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Christian Ehrhardt: > Great point intrigeri! > #1 > At least as far as my history analysis went this was triggered by ceph > having the support for lttng enabled. > Not by actually (trying to) enable the LTT-ng tracking. > While being disabled in ceph package since then it could show up in a > similar manner from almost any other source. > #2 > OTOH I never have seen any complains on LTT-ng not working in the virt > stack for the years carrying this delta. > So either it is not an issue to those using LTT-ng or no one > (statistically) uses it on virt-hosts in a case that would require it > to get these access. > Especially due to #1 IMHO I'd tend to add the denies as the flooding > hits people not explicitly enabling/caring about LTT-ng. > It would be great if instead of allow/deny we had the option to "deny > but report once" - like a ratelimit, but we don't. OK, why not then. My only remaining concern is that someone who wants to enable LTT-ng for their VMs (and somehow manages to guess that these two new rules break it) has to edit the libvirt-qemu abstraction directly: AFAIK there's no way to override them via a local/ include, because deny rules take precedence over allow rules. But anyway, we don't have any local/ include set up for this abstraction on Debian/Ubuntu currently, so for all practical matters it does not make a big difference. Thus, +1 for applying. And then let's keep our awareness level high and be ready to revert if we get bad feedback about it from !Ubuntu users :) Cheers, -- intrigeri -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Dec 21, 2017 at 11:50 AM, intrigeri <intrigeri+libvirt@boum.org> wrote: > Christian Ehrhardt: >> Great point intrigeri! > >> #1 >> At least as far as my history analysis went this was triggered by ceph >> having the support for lttng enabled. >> Not by actually (trying to) enable the LTT-ng tracking. >> While being disabled in ceph package since then it could show up in a >> similar manner from almost any other source. > >> #2 >> OTOH I never have seen any complains on LTT-ng not working in the virt >> stack for the years carrying this delta. >> So either it is not an issue to those using LTT-ng or no one >> (statistically) uses it on virt-hosts in a case that would require it >> to get these access. > >> Especially due to #1 IMHO I'd tend to add the denies as the flooding >> hits people not explicitly enabling/caring about LTT-ng. >> It would be great if instead of allow/deny we had the option to "deny >> but report once" - like a ratelimit, but we don't. > > OK, why not then. My only remaining concern is that someone who wants > to enable LTT-ng for their VMs (and somehow manages to guess that > these two new rules break it) has to edit the libvirt-qemu abstraction > directly: AFAIK there's no way to override them via a local/ include, > because deny rules take precedence over allow rules. But anyway, we > don't have any local/ include set up for this abstraction on > Debian/Ubuntu currently, so for all practical matters it does not make > a big difference. > > Thus, +1 for applying. Thanks > And then let's keep our awareness level high and be ready to revert if > we get bad feedback about it from !Ubuntu users :) Ack -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.