On 5/11/2023 12:05 AM, Tianjia Zhang wrote: > Separated fine-grained capability CAP_BLOCK_ADMIN from CAP_SYS_ADMIN. > For backward compatibility, the CAP_BLOCK_ADMIN capability is included > within CAP_SYS_ADMIN. > > Some database products rely on shared storage to complete the > write-once-read-multiple and write-multiple-read-multiple functions. > When HA occurs, they rely on the PR (Persistent Reservations) protocol > provided by the storage layer to manage block device permissions to > ensure data correctness. > > CAP_SYS_ADMIN is required in the PR protocol implementation of existing > block devices in the Linux kernel, which has too many sensitive > permissions, which may lead to risks such as container escape. The > kernel needs to provide more fine-grained permission management like > CAP_NET_ADMIN to avoid online products directly relying on root to run. > > CAP_BLOCK_ADMIN can also provide support for other block device > operations that require CAP_SYS_ADMIN capabilities in the future, > ensuring that applications run with least privilege. Can you demonstrate that there are cases where a program that needs CAP_BLOCK_ADMIN does not also require CAP_SYS_ADMIN for other operations? How much of what's allowed by CAP_SYS_ADMIN would be allowed by CAP_BLOCK_ADMIN? If use of a new capability is rare it's difficult to justify. > > Tianjia Zhang (2): > capability: Introduce CAP_BLOCK_ADMIN > block: use block_admin_capable() for Persistent Reservations > > block/ioctl.c | 10 +++++----- > include/linux/capability.h | 5 +++++ > include/uapi/linux/capability.h | 7 ++++++- > security/selinux/include/classmap.h | 4 ++-- > 4 files changed, 18 insertions(+), 8 deletions(-) >
