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

[Serge Hallyn]

It doesn't look to me like this is necessarily equivalent to CAP_SYS_ADMIN, so worth splittingoff. How about CAP_DRM_MASTER?

Apr 28, 2025 18:51:46 Luigi Semenzato <semenzato at google.com>:

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