Super user permissions needed for integration tests

[flxo]

Just a summary from #27:

The integration tests attach and detach loop devices. This is privileged operation that requires super user rights (or capabilities).
The tests are currently invoked in the CI with sudo to obtain those rights. Executing the tests during development with sudo is cumbersome because it leaves root owned files behind in the target tree.

An attempt to configure a runner that executes the tests with sudo in #27 solves the issue partially: Executing the tests works fine. But cargo doesn't make use of the runner when executing the doc tests which need the same permissions as the integration tests though.

[mdaffin]

Yes this is all less then ideal. My current workaround was just to run everything as root in vagrant. This lets you run all the tests as you would expect and does not clobber the permissions of your local checkout of the repo (as vagrant maps them back to your user).

I think it would be best if we can figure out a way to keep the doc tests enabled as that allows us to see when the examples have broken and need to be updated (nothing is more annoying than examples that don't compile). At the minimum a way to run the doc tests inside the CI system would be enough. It is a shame that changing the running does not affect the doc tests or this would have been a good (though still not ideal) solution.

Maybe we should just add to the README instructions on how to run them locally, such as this script:

mkdir -p .cargo
cat <<EOF >.cargo/config
[target.x86_64-unknown-linux-gnu]
runner = '.cargo/runner-x86_64-unknown-linux-gnu'
EOF
cat <<EOF >.cargo/runner-x86_64-unknown-linux-gnu
#!/usr/bin/env bash
sudo -E --preserve-env=PATH $@
EOF

And running only the tests with cargo test --test "*". This would allow you to run it outside of vagrant and ignore the doc tests locally without disabling them in the CI.

Wonder if there is a way to run them in an isolated environment with a micro kernel? Maybe with qemu? Not sure how hard that would be to setup though.

[mdaffin]

Loops like there is a new loopfs system that might allow us to create a new separate instance of the loop device files that we can use for testing. We might be able to use this to run the tests as a normal user if they are mounted with the right permissions? Would need to look at this new filesystem to see what it can do.

Raised a new issue #36 as it would also change how we construct the LoopControl device - though that might just be another constructor with the path prefix as a parameter.