Le 24/02/2026 à 22:30, Andrew Bower a écrit :
> The third scenario is more like the 'pledge' feature you describe, and
> this I think ought to meet with approval: before (or in the absence of)
> dropping to a non-root user, the application may drop some of root's
> capabilities (and elect to keep them when dropping user) to avoid
> keeping capabilities it knows it does not need. I don't think in most
> cases applications choose to keep CAP_SYS_ADMIN although they do often
> need CAP_DAC_OVERRIDE which is a bit of a scattergun it must be
> admitted.

    My limited experience on Linux capabilities is that this mechanism
is incompatible with suid root: an suid root program which has no
capabilities in its executable file cannot gain them despite its root
priviledge. This would be usefull because it could then drop its root
priviledge and be restricted to the capabilities it has set itself. The
consequence is that the capabilities must be stored in the (hidden)
extended attributes, in which case, of course, the program doesn't need
to be suid root.

    Landlock features a great deal of access rights to files and
directories, eg: write, create, truncate, delete, mv, are different
rights instead of being all controled by the only write permission. But
there is still no particular right associated to mount(), which opens a
large attack surface.

--     Didier