On Wed, Aug 17, 2022 at 7:53 AM Francis Laniel <flaniel@xxxxxxxxxxxxxxxxxxx> wrote: > Le mardi 16 août 2022, 23:59:41 CEST Paul Moore a écrit : > > On Mon, Jul 25, 2022 at 8:42 AM Francis Laniel > > > > <flaniel@xxxxxxxxxxxxxxxxxxx> wrote: > > > Hi. > > > > > > First, I hope you are fine and the same for your relatives. > > > > Hi Francis :) > > > > > A solution to this problem could be to add a way for the userspace to ask > > > the kernel about the capabilities it offers. > > > So, in this series, I added a new file to securityfs: > > > /sys/kernel/security/capabilities. > > > The goal of this file is to be used by "container world" software to know > > > kernel capabilities at run time instead of compile time. > > > > ... > > > > > The kernel already exposes the last capability number under: > > > /proc/sys/kernel/cap_last_cap > > > > I'm not clear on why this patchset is needed, why can't the > > application simply read from "cap_last_cap" to determine what > > capabilities the kernel supports? > > When you capabilities with, for example, docker, you will fill capabilities > like this: > docker run --rm --cap-add SYS_ADMIN debian:latest echo foo > As a consequence, the "echo foo" will be run with CAP_SYS_ADMIN set. > > Sadly, each time a new capability is added to the kernel, it means "container > stack" software should add a new string corresponding to the number of the > capabilities [1]. Thanks for clarifying things, I thought you were more concerned about detecting what capabilities the running kernel supported, I didn't realize it was getting a string literal for each supported capability. Unless there is a significant show of support for this - and I'm guessing there isn't due to the lack of comments - I don't think this is something we want to add to the kernel, especially since the kernel doesn't really care about the capabilities' names, it's the number that matters. -- paul-moore.com
