On Mon, 2016-04-04 at 08:23 -0400, Kyle Fazzari wrote: Often times the syscalls being made aren't strictly required (e.g. MySQL trying to control its thread priorities with `setpriority()`), which typically leads to my starting with (2) and moving to (3).
FYI, this particular syscall is going to be allowed soon once seccomp argument filtering lands, which should be before 16.04 release. Every time I do (3) however, I get the same question: "Why does Snappy use SECCOMP_RET_KILL instead of SECCOMP_RET_ERRNO?[1]" My only response is "I don't know." I'd like to stop saying that, thus this email :) . To make sure we're on the same page, Snappy's ubuntu-core-launcher uses libseccomp to load the filters, which it initializes with SCMP_ACT_KILL[2], which means that when a non-whitelisted syscall is made the caller is immediately killed with no chance to recover. Contrast this to SCMP_ACT_ERRNO which would allow for such syscalls to fail gracefully and be handled by the caller. For example, the code in MySQL would have handled this with no changes by printing a warning about being unable to change the priority-- perfect. But since Snappy uses SCMP_ACT_KILL it requires a code change to never attempt the call in the first place. This makes packaging snaps harder than it seems it needs to be, so I feel like there must be a good reason for it. The decision on which to use (KILL vs ERRNO) was an active one back in Capetown 2014 sprint (iirc), but perhaps it is time to revisit it based on this feedback. AppArmor uses deny and log so to me it makes some sense to do the same with seccomp. -- Jamie Strandboge | http://www.canonical.com -- Jamie Strandboge | http://www.canonical.com
signature.asc
Description: This is a digitally signed message part
-- snappy-devel mailing list snappy-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
