On Tue, Jul 28, 2015 at 5:43 PM, Kees Cook <[email protected]> wrote: > On Tue, Jul 28, 2015 at 4:41 AM, David Drysdale <[email protected]> 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 <[email protected]> >> Reviewed-by: Michael Kerrisk <[email protected]> > > This is great! > > Reviewed-by: Kees Cook <[email protected]> > > 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-api" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
