Building a binary with --enable-seccomp and then running it on a < 3.5
kernel, results in seccomp_load() failing and ocserv's worker process
aborting. This might be okay-ish for users who ./configure && make
install on their own systems but it's obviously non-ideal for e.g.
distributions that need to distribute binaries.
Unfortunately there doesn't seem to be a good way (that I could find) to
check if the running kernel has seccomp -- uname/uts isn't a good
solution as Ubuntu has backported it to 3.2, custom kernels might have
CONFIG_SECCOMP=n etc.
So, this makes a tradeoff call and removes the exit_worker() call on
seccomp failures, lowers the seccomp error logs to LOG_DEBUG from
LOG_WARNING and the "could not disable system calls" to LOG_INFO from
LOG_ERR.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
libseccomp has a bug where -EDOM is returned when seccomp_rule_add is
called for pseudo system calls (i.e. < -99). This was triggered by
adding the send() system call on my x86_64 machine. The bug seems to
have been recently (May 7th, 2013) reported and fixed on libseccomp
upstream but it will take a while to find its way to a release and
distributions.
Additionally, there was a bug on how libseccomp calls were error
handled: libseccomp functions don't actually set errno, but set errno
values in their return value instead. This resulted in the
seccomp_rule_add call above to print "could not add send to seccomp
filter: Success".
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
