linux-kernel - Re: IOPRIO_CLASS_RT without CAP_SYS

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <992ed2ed-f644-a5ad-3239-b38ddeafe28b@acm.org>
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.