Messages in this thread | | | From | David Drysdale <> | Date | Fri, 31 Jul 2015 15:42:53 +0100 | Subject | Re: [PATCHv2 1/1] Documentation: describe how to add a system call |
| |
On Fri, Jul 31, 2015 at 2:06 PM, Josh Triplett <josh@joshtriplett.org> 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@joshtriplett.org> 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...
| |