FYI: non-standard use of O_PATH fds in BPF_OBJ_GET and BPF_OBJ_PIN

[Paul Moore]

This shouldn't impact any in-tree LSMs[1], but I wanted to make
everyone aware that there is a eBPF patchset being discussed which
does some unusual things, namely treating fd 0 as AT_FDCWD in
BPF_OBJ_GET and BPF_OBJ_PIN.  If you are working on a new LSM, or
adding eBPF controls to an existing LSM, you might want to check the
discussion linked below:

* https://lore.kernel.org/all/20230516001348.286414-1-andrii@kernel.org/

[1] Only SELinux currently implements any eBPF controls, and even then
it only enforces policy on BPF_MAP_CREATE and BPF_PROG_LOAD.  Not to
mention that SELinux applies its security policy based on the label
associated with the file/inode, not the pathname.  Regardless of how
the path is resolved, or even if it is resolved correctly, SELinux
will still properly enforce the loaded security policy.

-- 
paul-moore.com