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

[Casey Schaufler]

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!
>>