how are new CAP_* added? CAP_{DISPLAY,DRM,GPU}?

[Luigi Semenzato]

"DRM" stands for Direct Rendering Manager, which I understand is the
standard way of accessing the GPU on the (vast?) majority of modern
Linux systems, for the purpose of producing output on the display.
(Other googlers on this thread would know better---for instance I
don't know if DRM is used also for general-purpose computing on the
GPU.)

The DRM master essentially owns the display, so this may be similar to
the totality of the CAP_NET_* capabilities.  Also similar to
CAP_SYS_TIME, as it refers to a large class of hardware components.

OTOH, just by looking at capability.h I am seeing that there is a lot
of competition for those bits!

I am wondering if this has come up for discussion before.  I couldn't
find references to it.  Probably because it just isn't a good
candidate.

On Mon, Apr 28, 2025 at 4:16 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>
> On 4/28/2025 3:19 PM, Luigi Semenzato wrote:
> > I have a use case for adding a CAP_DRM, or similar, to replace the
> > CAP_SYS_ADMIN in drivers/gpu/drm/drm_auth.c for the purpose of
> > becoming the DRM master.
> >
> > I am not an expert on either DRM or capabilities, and I am wondering
> > how one can decide the appropriate level of granularity for a new
> > capability.  Is CAP_DRM general enough (but not too much), or should
> > it be CAP_GPU, or CAP_DISPLAY?  Or perhaps capabilities should be
> > discouraged for this case?
>
> There are a limited number (64) of capabilities available, so we're
> being careful about handing them out. My first question is one of generality.
> If there is only one case where the capability is useful, there's really no
> way to justify it. If a process would need another capability (typically
> CAP_SYS_ADMIN) in all cases, there's no point in a separate one. If the
> use case isn't going to be around more or less permanently, or it is unique
> to a hardware platform, we won't approve it. Without knowing what a "DRM master"
> is, it's difficult to say for sure, but I'm guessing you are going to be up
> against all these criteria.
>
> >
> > Thanks!
> >
> >
> > On Mon, Apr 28, 2025 at 3:16 PM Luigi Semenzato <semenzato at google.com> wrote:
> >> I have a use case for adding a CAP_DRM, or similar, to replace the CAP_SYS_ADMIN in drivers/gpu/drm/drm_auth.c for the purpose of becoming the DRM master.
> >>
> >> I am not an expert on either DRM or capabilities, and I am wondering how one can decide the appropriate level of granularity for a new capability.  Is CAP_DRM general enough (but not too much), or should it be CAP_GPU, or CAP_DISPLAY?  Or perhaps capabilities should be discouraged for this case?
> >>
> >> Thanks!
> >>