Quoting Christoph Lameter (cl@xxxxxxxxx): > On Tue, 24 Feb 2015, Serge E. Hallyn wrote: > > > The other way to look at it then is that it's basically as though the > > privileged task (which has CAP_SETFCAP) could've just added fI=full to > > all binaries on the filesystem; instead it's using the ambient set > > so that the risk from fI=full is contained to its own process tree. > > The way that our internal patch works is to leave these things alone and > just check the ambient mask in the *capable*() functions. That way the > behavior of the existing cap bits does not change but the ambient caps > stay available. Apps have no surprises. Unless I'm misunderstanding what you are saying, apps do have surprises. They drop capabilities, execute a file, and the result has capabilities which the app couldn't have expected. At least if the bits have to be in fI to become part of pP', the app has a clue. To be clear, I'm suggesting that the rules at exec become: pI' = pI pA' = pA (pA is ambient) pP' = (X & fP) | (pI & (fI | pA)) pE' = pP' & fE -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html