Hi,
I’m attempting to implement BPF Token support in Aya using the implementation in
libbpf and the kernel selftests as a reference. However, I’m hitting issues.
I'm performing the following operations:
1. Creating a bpffs (using fsopen, fsconfig, fsmount) for my UID/GID 1000 with
“any” prog/map/cmd allowed:
$ mount | grep /tmp/bpffs
none on /tmp/bpffs type bpf (rw,relatime,uid=1000,gid=1000,delegate_cmds=any,delegate_maps=any,delegate_progs=any,delegate_attachs=any)
2. I’m creating a new userns with bwrap:
bwrap --unshare-user --unshare-ipc --unshare-pid --unshare-net \
--unshare-uts --unshare-cgroup --uid 0 --gid 0 \
--bind /var/lib/images/fedora / --dev-bind /dev /dev \
--bind /tmp/bpffs /sys/fs/bpf --bind ${PWD} /home/dave \
--cap-add CAP_BPF --proc /proc -- /bin/bash
3. I’m then executing my BPF application inside the userns:
./xdp-test
However, what I’m observing is that my program is failing to load.
strace confirms I’m getting -EINVAL from BPF_TOKEN_CREATE.
$ strace ./xdp-test
...
open("/sys/fs/bpf", O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 9
bpf(BPF_TOKEN_CREATE, {token_create={flags=0, bpffs_fd=9}}, 152) = -1 EPERM (Operation not permitted)
…
I believe I have CAP_BPF inside the userns also:
$ getpcaps 2 # pid of bash
2: cap_bpf=eip
My machine is running on Kernel 6.9.4.
The only difference I can see between my code and the selftest is that the
selftest os performing the fsopen from within the userns, which looks like it
is deliberate in order to check you can’t set delegation options from within
the userns.
It’s quite possible there’s a bug in my implementation but before I try the
same operations with libbpf directly I’d really appreciate a sanity check
that I’m using BPF Token in the correct way first.
TL;DR
If I create a bpffs in the init user ns, then bind mount it into a userns,
will BPF Token work?
Thanks in advance,
-- Dave
