On Tue, Jul 28, 2015 at 5:43 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Tue, Jul 28, 2015 at 4:41 AM, David Drysdale <drysdale@xxxxxxxxxx> wrote: >> Add a document describing the process of adding a new system call, >> including the need for a flags argument for future compatibility, and >> covering 32-bit/64-bit concerns (albeit in an x86-centric way). >> >> Signed-off-by: David Drysdale <drysdale@xxxxxxxxxx> >> Reviewed-by: Michael Kerrisk <mtk.manpages@xxxxxxxxx> > > This is great! > > Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> > > I have a few minor suggestions below... Thanks, I've applied all bar one -- a query below. >> --- >> Documentation/adding-syscalls.txt | 454 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 454 insertions(+) >> create mode 100644 Documentation/adding-syscalls.txt >> >> diff --git a/Documentation/adding-syscalls.txt b/Documentation/adding-syscalls.txt >> new file mode 100644 >> index 000000000000..5f52edda8951 >> --- /dev/null >> +++ b/Documentation/adding-syscalls.txt [snip] >> + - 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. > > Perhaps mention alternative mechanisms for access control when working > on file descriptors, like avoiding security issues by looking at fd > _opener_ credentials, rather than current's credentials? I'm struggling to cope up with text about this that doesn't feel either too vague or much too detailed / internal, so maybe I'm misunderstanding what you're after. Could you clarify or maybe suggest a sentence or two? Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html