On Fri, Jul 31, 2015 at 2:06 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote: > On Fri, Jul 31, 2015 at 10:48:32AM +0100, David Drysdale wrote: >> On Thu, Jul 30, 2015 at 7:50 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote: >> > On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote: >> >> +needs to be governed by the appropriate Linux capability bit (checked with a >> >> +call to capable()), as described in the capabilities(7) man page. >> >> + >> >> + - If there is an existing capability that governs related functionality, then >> >> + use that. However, avoid combining lots of only vaguely related functions >> >> + together under the same bit, as this goes against capabilities' purpose of >> >> + splitting the power of root. In particular, avoid adding new uses of the >> >> + already overly-general CAP_SYS_ADMIN capability. >> >> + - If there is no related capability, then consider adding a new capability >> >> + bit -- but bear in mind that the numbering space is limited, and each new >> >> + bit needs to be understood and administered by sysadmins. >> > >> > Many previous discussions on this topic seem to have concluded that it's >> > almost impossible to add a new capability without breaking existing >> > programs. I would suggest not even mentioning this possibility. >> >> I'm not particularly knowledgable about capabilities (at least, not the >> POSIX.1e/Linux kind), so I'll confess that I got this suggestion from >> Michael Kerrisk. >> >> Michael, do you agree that we should just drop the possibility of adding >> new capability bits? >> >> Also, Josh, do you have any references to the earlier discussions on the >> topic so I can update the Sources section? > > No direct links handy at the moment without some searching, but one > iteration of it came up when Matthew Garrett suggested adding > CAP_COMPROMISE_KERNEL, and the ensuing discussion of capability > semantics suggested that the way the capability space was defined and > controlled by userspace meant that adding any new capability would > effectively break userspace ABI. The userspace ABI for capabilities is > not clear; some applications drop all possible capabilities and could > get surprised by a new capability being dropped, while other > applications drop only capabilities they know about and could get > surprised by a new capability *not* being dropped. BTW, I left this paragraph unchanged in the v3 version I just sent out -- I'll update it for v4 when I get back from vacation, depending on what discussion occurs in the meantime... -- 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
