MATCH is a wrapper around grep -E -q, thus MATCH -v ends up being grep -E -q -v.
However, grep -v is peculiar as far as exit codes are concerned, and returns 0
when lines not matching the pattern were found in the input.
For example, this command returns 1:
$ cat <<EOF | grep -E -v foo
foo
foo
foo
EOF
but this one returns 0, even though the pattern we don't want is in the input:
cat <<EOF | grep -E -v foo; echo $?
foo
bar
baz
EOF
In the tests, MATCH -v is used to check that the pattern does not appear in the
input, which is incorrect.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Currently we use mem device on the tests but it is not allowed to access
on arm device such as rpi3 and dragonboard. The idea is to use random
device instead.
example for rpi3:
test@localhost:~$ dd if=/dev/mem of=/dev/null count=10
dd: failed to open '/dev/mem': Permission denied
test@localhost:~$ dd if=/dev/random of=/dev/null count=10
10+0 records in
10+0 records out
5120 bytes (5.1 kB, 5.0 KiB) copied, 0.00265199 s, 1.9 MB/s
This change makes more simple the snaps used and changes the char device
used which was causing issues sporadically.
The errror in travis:
google:arch-linux-64 .../tests/main/security-device-cgroups-devmode#
test-devmode-cgroup.read-kmsg
head: error reading '/dev/kmsg': Broken pipe
The tests that check if the device cgroup works for framebuffer
devices is broken currently on devices that have an active
framebuffer. We did not notice so far because all virtual machines
we use to test do not have a framebuffer device.
However devices like the pi2/pi3 have framebuffers. There it is
not enough to create /dev/fb255 because the cgroup for framebuffer
device is active (it contains fb0). On machines that do not have
any framebuffer device the device cgroup is not active and we only
test that the apparmor based access is working.
The fix is to always use "fb0" in the tests and only create it
if it is missing. On systems were it is missing we tests the
apparmor based permissions as before. But on systems with a
framebuffer we now test also the right device in the cgroup
so that the test can actually work, i.e. snap-confine will
add the right (fb0) udev device to the devices cgroup. The
artificially created fb255 that was used before was not known
to udev and therefore not added by snap-confine to the devices
cgroup.
devmode and classic snaps are meant to run without confinement, but the udev
backend unconditionally udev tags devices resulting in permission denied errors
when for devices not in connected interfaces. While classic snaps currently
aren't allowed to plugs interfaces, this is expected to change so fix this now
too.
Reference:
https://forum.snapcraft.io/t/device-cgroup-is-applied-to-devmode-snap/2663
While we could simply not generate the files in /etc/udev/rules.d when in
devmode or classic, we instead generate those files with commented out the
udev rules. This makes the testsuite changes much smaller, but also allows
someone working in devmode to see what would be done, and to adjust the file in
/etc/udev/rules.d as needed when developing their snap.
This adds four spread tests: devmode, classic, jailmode and strict mode. While
much of the cgroup handling is done in tests/main/security-device-cgroups,
these tests are more about high-level blackbox testing in the manner a
developer would experience things.
