On 12/16/20 2:29 PM, Lorenz Bauer wrote:
Hi,
We're currently in the process of deploying our BPF socket dispatch
control plane. This is the first piece of code where we persist maps
my pinning them into a bpffs. We tried using /sys/fs/bpf but ran into
permission problems:
$ ls -ld /sys/fs/bpf
drwx-----T 2 root root 0 Dec 10 21:48 /sys/fs/bpf
For various reasons our program has a dedicated user, so we can't
access /sys/fs/bpf. I did some digging into how the mode came about.
In our environment the mount is done by systemd:
* First, systemd mounted without explicit mode set [1]. I think this
means originally the mode was 1777.
* Second, systemd changed this to 0700 [2]. The commit references some
discussion with BPF folks, but I can't find a source for this
discussion.
What were the reasons for changing the mode to 0700? Would it be
reasonable to mount /sys/fs/bpf with 1777 nowadays?
If you don't specify anything particular a3af5f800106 ("bpf: allow for
mount options to specify permissions") the sb is created with S_IRWXUGO.
It's probably caution on systemd side (?), currently don't recall any
particular discussion on this matter.
Either way, you can mount your own private instance of bpf fs instance
anyway which supports anyway different mount flavors if needed [0]. So
it's no different from tmp fs or others - apart from explicitly not
having userns support.
[0] https://www.kernel.org/doc/html/latest/filesystems/sharedsubtree.html
Thanks
Lorenz
1: https://github.com/systemd/systemd/commit/43b7f24b5e0dd048452112bfb344739764c58694
2: https://github.com/systemd/systemd/commit/39f305a901934dfcc064cffd4e419b92d90b02c0
--
Lorenz Bauer | Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
www.cloudflare.com
