lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 22 Aug 2020 18:58:04 -0700 From: Bart Van Assche <bvanassche@....org> To: Khazhismel Kumykov <khazhy@...gle.com>, axboe@...nel.dk, paolo.valente@...aro.org Cc: linux-block@...r.kernel.org, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: IOPRIO_CLASS_RT without CAP_SYS_ADMIN? On 2020-08-20 17:35, Khazhismel Kumykov wrote: > It'd be nice to allow a process to send RT requests without granting > it the wide capabilities of CAP_SYS_ADMIN, and we already have a > capability which seems to almost fit this priority idea - > CAP_SYS_NICE? Would this fit there? > > Being capable of setting IO priorities on per request or per thread > basis (be it async submission or w/ thread ioprio_set) is useful > especially when the userspace has its own prioritization/scheduling > before hitting the kernel, allowing us to signal to the kernel how to > order certain IOs, and it'd be nice to separate this from ADMIN for > non-root processes, in a way that's less error prone than e.g. having > a trusted launcher ionice the process and then drop priorities for > everything but prio requests. Hi Khazhy, In include/uapi/linux/capability.h I found the following: /* Allow raising priority and setting priority on other (different UID) processes */ /* Allow use of FIFO and round-robin (realtime) scheduling on own processes and setting the scheduling algorithm used by another process. */ /* Allow setting cpu affinity on other processes */ #define CAP_SYS_NICE 23 If it is acceptable that every process that has permission to submit IOPRIO_CLASS_RT I/O also has permission to modify the priority of other processes then extending CAP_SYS_NICE is an option. Another possibility is to extend the block cgroup controller such that the capability to submit IOPRIO_CLASS_RT I/O can be enabled through the cgroup interface. There may be other approaches. I'm not sure what the best approach is. Bart.
Powered by blists - more mailing lists