System log entries - apparmor and /usr/bin/man

A

aerodinamica

New Member
Aug 19, 2025
5
0
1
I am running Proxmox VE 9.0.5 on a newly built computer. Everytime I run 'man' to read the manual for some command, I get six entries (with six different pid's) like these in the system log:

kernel: audit: type=1400 audit(1755596132.009:125): apparmor="DENIED" operation="capable" class="cap" profile="/usr/bin/man" pid=4172 comm="man" capability=21 capname="sys_admin"

This does not happen with an older computer running VE 8.4.9. Any ideas? Why would man need sys_admin capabilities?
 
Hi!

Have you set up any man pager with the MANPAGER environment variable (echo $MANPAGER)? Either way, the audit message doesn't say much, but I can only guess that it could be about the seccomp(...) syscalls that man does make at startup to confine any children processes (like pagers, groff formatters, ...), but fails to set them because those need SYS_ADMIN capabilities. Do the other log messages tell more about the actual error? What is the output of a strace -Z man man > /dev/null?

NOTE: strace can potentially output information that you wouldn't want the whole forum to see, but with -Z it only outputs failed syscalls. Either way, check what information is posted before submitting.
 
Last edited:
FYI, one rather insecure way to mitigate this is to disable the apparmor profile for now with aa-disable /usr/bin/man or another slightly better solution is to use aa-logprof (in apparmor-utils package) which allows modifying the apparmor profile with interactive suggestions, but the latter should also be used with caution if one's not familiar with apparmor rules.
 
Hi!

Thanks for your suggestions. MANPAGER is not set. Overall, this is a rather standard, "vanilla" Proxmox 9 installation. I haven't made any major modifications since I want this node to be easily replaceable.

There are no other log entries, and the man command itself works just fine.

The strace returns loads of ENOENTs, some EINVALs and also this group of seccomp calls twice:

seccomp(SECCOMP_SET_MODE_STRICT, 0x1, NULL) = -1 EINVAL (Invalid argument)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_LOG, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_SPEC_ALLOW, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_NEW_LISTENER, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC_ESRCH, NULL) = -1 EFAULT (Bad address)
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_NEW_LISTENER|SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV, NULL) = -1 EFAULT (Bad address)

I guess they might be related to apparmor since there are six of the EFAULTs, but that is a long shot.

Edit: Also found this in the manpage for seccomp. SYS_ADMIN seems familiar...

In order to use the SECCOMP_SET_MODE_FILTER operation,
either the calling thread must have the CAP_SYS_ADMIN
capability in its user namespace, or the thread must
already have the no_new_privs bit set.
Click to expand...
 
Last edited:
An update on this issue. Due to other reasons I reinstalled Proxmox 9 on this node, and the apparmor warnings about man are still present in the logs. These are the only changes that I have made to this node since installation:
  • Enabled PVE No-Subscription Repository for PVE and Ceph. Disabled the Enterprise variants. Did an apt update & full-upgrade.
  • Installed VIM, iperf3 and needrestart.
  • Setup mail notifications via Gmail.
  • Installed snmpd and added a v3 user.
  • Created ZFS datasets and some datacenter storage.
  • Activated datacenter and node firewall and added some rules.
  • Created a network bridge for my second NIC.
These are literally the only steps that I have taken. I can't see how any of these would interfere with man. Should I file a bug report with Proxmox?
 
I can concur, entering the command: man man on my basically vanilla PVE9 (updated from 8) produced these 6 lines:
Code: 
Aug 24 14:42:52 REDACTED kernel: audit: type=1400 audit(1756035772.251:1919): apparmor="DENIED" operation="capable" class="cap" profile="/usr/bin/man" pid=1342725 comm="man" capability=21  capname="sys_admin"
Aug 24 14:42:52 REDACTED kernel: audit: type=1400 audit(1756035772.253:1920): apparmor="DENIED" operation="capable" class="cap" profile="/usr/bin/man" pid=1342727 comm="man" capability=21  capname="sys_admin"
Aug 24 14:42:52 REDACTED kernel: audit: type=1400 audit(1756035772.254:1921): apparmor="DENIED" operation="capable" class="cap" profile="/usr/bin/man" pid=1342728 comm="man" capability=21  capname="sys_admin"
Aug 24 14:42:52 REDACTED kernel: audit: type=1400 audit(1756035772.254:1922): apparmor="DENIED" operation="capable" class="cap" profile="/usr/bin/man" pid=1342726 comm="man" capability=21  capname="sys_admin"
Aug 24 14:42:52 REDACTED kernel: audit: type=1400 audit(1756035772.257:1923): apparmor="DENIED" operation="capable" class="cap" profile="/usr/bin/man" pid=1342730 comm="man" capability=21  capname="sys_admin"
Aug 24 14:42:52 REDACTED kernel: audit: type=1400 audit(1756035772.257:1924): apparmor="DENIED" operation="capable" class="cap" profile="/usr/bin/man" pid=1342729 comm="man" capability=21  capname="sys_admin"
Also when pressing the "q" button to return to the shell, I get:
Code: 
man: can't resolve man7/groff_man.7
 
i'm also observing this exact behaviour and think the groff error message is a result of this. that should be fixed. we should file a bugzilla ticket
 
Last edited:
You must log in or register to reply here.
Top Bottom