On 2/13/25 07:57, Hector Cao wrote:
For executables dynamically linked to libnuma, the runtimer linker
invokes libnuma functions (num_init) that try to access
/sys/devices/system/node/ and if the application's apparmor
profile does not allow this access, this access will be denied
by apparmor with following error message:
apparmor="DENIED" operation="open" class="file"
name="/sys/devices/system/node/" comm="qemu-bridge-hel"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Here is the simplified call trace:
0 ... in ?? () from /lib/x86_64-linux-gnu/libnuma.so.1
1 ... in call_init (...) at ./elf/dl-init.c:74
2 ... in call_init (...) at ./elf/dl-init.c:120
3 _dl_init (...) at ./elf/dl-init.c:121
4 ... in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
Allow access to this sysfs folder so that we do not have to
specify this permission for every executable linked to libnuma
what is the advantage of not specifying it? abstractions/base
violates POLA and needs to go away. So I am very reluctant to
add anything to base.
Instead of adding the rule to every application linking to
libnuma we should probably have a numa abstraction. While it
would have 1 rule atm. As we deconstruct base it will pick up
a few other rules.
Changes in v2:
- Fix typo: add missing ending '/' character to the path
Signed-off-by: Hector Cao <hector....@canonical.com>
---
profiles/apparmor.d/abstractions/base | 2 ++
1 file changed, 2 insertions(+)
diff --git a/profiles/apparmor.d/abstractions/base
b/profiles/apparmor.d/abstractions/base
index bf3f3184e..52cbab920 100644
--- a/profiles/apparmor.d/abstractions/base
+++ b/profiles/apparmor.d/abstractions/base
@@ -108,6 +108,8 @@
@{sys}/devices/system/cpu/ r,
@{sys}/devices/system/cpu/online r,
@{sys}/devices/system/cpu/possible r,
+ # runtime initialization for binaries linked to libnuma
+ @{sys}/devices/system/node/ r,
# transparent hugepage support
@{sys}/kernel/mm/transparent_hugepage/hpage_pmd_size r,
