Comment 7 for bug 1465724

If we want to track down the kernel code that is triggering this capable() check when running as root, here's a stack trace called from AppArmor's audit_caps() function. Note that I generated this on a vanilla kernel (4.1-rc8).

CPU: 1 PID: 2199 Comm: go Not tainted 4.1.0-rc8+ #120
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 00000000ffffffff ffff880079ff3a88 ffffffffb0634f04 0000000080000001
 0000000000001000 ffff880079ff3b48 ffffffffb0348bf1 ffff88007f9d75d0
 00000000001d2480 0000000c00000007 00000000001d2480 ffff880079ff3a03
Call Trace:
 [<ffffffffb0634f04>] dump_stack+0x4f/0x7b
 [<ffffffffb0348bf1>] aa_capable+0x321/0x330
 [<ffffffffb035271d>] apparmor_capable+0x4d/0x70
 [<ffffffffb030d528>] security_capable+0x18/0x20
 [<ffffffffb00719ec>] ns_capable+0x3c/0x70
 [<ffffffffb062a05a>] net_ctl_permissions+0x4a/0xd0
 [<ffffffffb0270370>] proc_sys_permission+0x70/0xc0
 [<ffffffffb01f9c0f>] __inode_permission+0x6f/0xd0
 [<ffffffffb01f9c88>] inode_permission+0x18/0x50
 [<ffffffffb01fcfbb>] link_path_walk+0x6b/0x970
 [<ffffffffb03c7587>] ? debug_smp_processor_id+0x17/0x20
 [<ffffffffb00bef7e>] ? put_lock_stats.isra.22+0xe/0x30
 [<ffffffffb00bf027>] ? lock_release_holdtime.part.23+0x87/0x170
 [<ffffffffb01fd979>] path_init+0xb9/0x880
 [<ffffffffb01fefe6>] ? path_openat+0x66/0x6a0
 [<ffffffffb01fefe6>] path_openat+0x66/0x6a0
 [<ffffffffb000e5b9>] ? sched_clock+0x9/0x10
 [<ffffffffb00a30c5>] ? sched_clock_local+0x25/0x90
 [<ffffffffb02100cf>] ? __alloc_fd+0xaf/0x190
 [<ffffffffb03c7587>] ? debug_smp_processor_id+0x17/0x20
 [<ffffffffb00be3cb>] ? get_lock_stats+0x2b/0x60
 [<ffffffffb02005aa>] do_filp_open+0x3a/0xb0
 [<ffffffffb02100cf>] ? __alloc_fd+0xaf/0x190
 [<ffffffffb0127464>] ? __audit_syscall_entry+0xb4/0x110
 [<ffffffffb01eceb6>] do_sys_open+0x126/0x220
 [<ffffffffb0014433>] ? syscall_trace_enter_phase1+0x103/0x170
 [<ffffffffb01ecfce>] SyS_open+0x1e/0x20
 [<ffffffffb063e42e>] system_call_fastpath+0x12/0x76