seccomp filters: Why kill?

[Didier Roche]

Le 04/04/2016 21:33, Jamie Strandboge a écrit :
> On Mon, 2016-04-04 at 14:56 -0400, Kyle Fazzari wrote:
>> On 04/04/2016 02:03 PM, Jamie Strandboge wrote:
>>> 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.
>> I agree. I also imagine upstream contributions to deal with ERRNO will
>> be viewed as making things more robust rather than "make this work with
>> Snappy." Do you remember the original rational for using KILL?
>>
> I do not; perhaps others on this list do.

Just to add another use case, I got exactly the same issue (with
setpriority even! ;)) on ffmepg, where the error is dealt internally in
code, but we didn't give it a chance to handle that exception by
returning an ERRNO instead of quickly killing it.

I think that most of upstream code is handling those kind of try/expect
cases and it would be better in case of denials, to let them handling it
(maybe their handling will be then exit(1), fine in that case)? This is
typically what is used with the new dynamic security permissions on
Android for instance.

Cheers,
Didier