Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753199AbbGaOnQ (ORCPT ); Fri, 31 Jul 2015 10:43:16 -0400 Received: from mail-vk0-f48.google.com ([209.85.213.48]:32834 "EHLO mail-vk0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751833AbbGaOnO (ORCPT ); Fri, 31 Jul 2015 10:43:14 -0400 MIME-Version: 1.0 In-Reply-To: <20150731130620.GA16435@x> References: <1438242731-27756-1-git-send-email-drysdale@google.com> <1438242731-27756-2-git-send-email-drysdale@google.com> <20150730185007.GC16452@x> <20150731130620.GA16435@x> From: David Drysdale Date: Fri, 31 Jul 2015 15:42:53 +0100 Message-ID: Subject: Re: [PATCHv2 1/1] Documentation: describe how to add a system call To: Josh Triplett Cc: Michael Kerrisk , Linux API , Andrew Morton , Arnd Bergmann , Shuah Khan , Jonathan Corbet , Eric B Munson , Randy Dunlap , Andrea Arcangeli , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Oleg Nesterov , Linus Torvalds , Greg Kroah-Hartman , Andy Lutomirski , Al Viro , Rusty Russell , Peter Zijlstra , Vivek Goyal , Alexei Starovoitov , David Herrmann , "Theodore Ts'o" , Kees Cook , Miklos Szeredi , Milosz Tanski , Fam Zheng , Mathieu Desnoyers , linux-doc@vger.kernel.org, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2819 Lines: 49 On Fri, Jul 31, 2015 at 2:06 PM, Josh Triplett 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 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/