[patch] syscall.sh test fails if kernel has CONFIG_SYSCTL_SYSCALL=n

[Simon McVittie]

The syscall.sh test fails if your kernel has the sysctl() syscall compiled out. It looks as though it's meant to skip that part on such kernels, but the ability to do so might have regressed at some point.

Partial log with "bash -x":

+ bash syscall_sysctl.sh
FAIL: sysctl read failed - Function not implemented
Fatal Error (syscall_sysctl): Unexpected shell error. Run with -x to debug
++ error_handler
++ fatalerror 'Unexpected shell error. Run with -x to debug'
++ '[' -z '' ']'
++ _fatal=true
++ echo 'Fatal Error (syscall_mknod): Unexpected shell error. Run with -x to debug'
Fatal Error (syscall_mknod): Unexpected shell error. Run with -x to debug
++ exit 127
+ exit_handler

Attaching a patch which addresses this:

From: Simon McVittie <email address hidden>
Date: Wed, 11 May 2016 13:52:56 +0100
Subject: syscall_sysctl test: correctly skip if CONFIG_SYSCTL_SYSCALL=n

This test attempts to auto-skip the sysctl() part if that syscall
was not compiled into the current kernel, via
CONFIG_SYSCTL_SYSCALL=n. Unfortunately, this didn't actually work,
for two reasons:

* Because "${test} ro" wasn't in "&&", "||", a pipeline or an "if",
  and it had nonzero exit status, the trap on ERR was triggered,
  causing execution of the error_handler() shell function, which
  aborts the test with a failed status. The rules for ERR are the
  same as for "set -e", so we can circumvent it in the same ways.
* Because sysctl_syscall.c prints its diagnostic message to stderr,
  but the $() operator only captures stdout, it never matched
  in the string comparison. This is easily solved by redirecting
  its stderr to stdout.

Signed-off-by: Simon McVittie <email address hidden>

[Seth Arnold (seth-arnold)]

Nice debugging. I've checked this into the master: Committed revision 3446.
Thanks

[Seth Arnold (seth-arnold)]

I also checked this into 2.9 and 2.10. Thanks.

[Christian Boltz (cboltz)]

Fixed in AppArmor 2.11, 2.10.2 and 2.9.4