On Friday, November 22, 2013 11:39:31 AM Stefan Hajnoczi wrote: > On Thu, Nov 21, 2013 at 10:48:58AM -0500, Paul Moore wrote: > > I'm always open to suggestions on how to improve the development/debugging > > process, so if you have any ideas please let me know. > > The failure mode is terrible:
Glad to see you don't feel strongly about things. > "The following fails to start here (the shell hangs and ps shows QEMU > is a <defunct> process)" > > When a process dies the shell prints a warning. That alerts the user > and prompts them to take further steps. > > Hanging the shell is a really bad way to fail. We can't expect users to > begin searching logs for audit failures. They probably don't even know > about audit or seccomp. First things first, if a normal user hits a seccomp failure I consider it to be a bug, and to be honest, I've seen much nastier, much more subtle bugs than an inadvertent seccomp "death". In a perfect world only developers would run into this problem and I would expect developers to be smart enough to figure out what is going on. Getting past that, if seccomp is configured to kill the process when it violates the filter rules there isn't much else we can do; the kernel kills the process and then the rest of userspace, e.g. the shell/libvirt/etc., does whatever it does. We have very little control over things. > Is it possible to produce output when a seccomp violation takes place? See the earlier comments from Eduardo about his attempts in this area. -- paul moore security and virtualization @ redhat