adding CAP_RESERVED_# bits

[Serge E. Hallyn]

Sorry... why not just request a real capability bit be reserved?

Ok, I see at https://lore.kernel.org/all/?q=Luigi%20Semenzato%20capability
that Casey was suitably cautious.  However, I'd say if we end up needing to do
the painful transition to 128bit caps, we should face that, rather than
make people do ugly hacks.

-serge

On Fri, Jun 27, 2025 at 01:26:54PM -0700, Luigi Semenzato wrote:
> Sorry for the delay in responding, and thank you so much for
> clarifying the Linux priorities.
> 
> For our project we ended up hijacking an existing bit which we're
> comfortably sure we won't need for that binary (or any binary,
> really), plus a seccomp filter.  It's a total hack, but a simple one,
> and it beats the alternatives.
> 
> 
> On Fri, Jun 6, 2025 at 7:11 PM Paul Moore <paul at paul-moore.com> wrote:
> >
> > On Fri, Jun 6, 2025 at 1:58 PM Luigi Semenzato <semenzato at google.com> wrote:
> > >
> > > Recently I inquired about the decision process for adding a CAP_DRM
> > > bit to capability.h (to become DRM master).  It occurred to me that
> > > the process for adding ANY bit would be fraught with controversies (to
> > > say the least).
> > >
> > > So I looked into maintaining a patch in our own kernel sources, but
> > > that was surprisingly messy due to the build-time dependencies of
> > > capability.h and the way we maintain and share sources internally for
> > > multiple kernel versions.  This would have been quite simple if there
> > > were a few reserved bits, such as CAP_RESERVED_0, ..,
> > > CAP_RESERVED_<N-1> with, say, N=3.
> > >
> > > Would this also be controversial?
> >
> > Yes, and likely rejected too.  The upstream Linux kernel generally
> > doesn't make any sacrifices to support out-of-tree kernel code, and
> > giving up precious capability bitmap space would definitely be
> > considered a sacrifice.
> >
> > --
> > paul-moore.com