Introduce unshare-harder variant of brickstrap.sh.

[cmacq2]

This is Debian specific fallback version which will first prod the kernel into allowing ordinary users to unshare, as this is a necessary for user-unshare.pl on recent-ish Debian. Any changes to original kernel settings are reverted on exit. This workaround avoids having to run the entire brickstrap with sudo/su or to change the default unshare policy permanently. Only the initial prodding and reverting need sudo/su privileges.

By request the unshare-harder variant was split off into a PR of its own, from #12 Continuing the comment thread:

• The purpose of the unshare-harder variant is to avoid having to run the actual brickstrap command with elevated privileges, essentially extracting the privileged operations into well-defined, limited commands that do not touch files in the user's home directory.
• This avoids running brickstrap as root even if unshare() is disabled for ordinary users by default on Debian. Running brickstrap with sudo or su would be quite a bad idea and rather ignore the entire raison d' être of brickstrap.
• Using sudo su means that the user can simply input their 'normal' password instead of the password for root. This may be useful in scenarios where root isn't setup for login shells (as with e.g. Ubuntu by default) or they lack the root password. The downside is that the script requires sudo (in addition to su) which you may or may not find a gratuitous dep. It's possible to make the exact choice (sudo su or plain su) configurable using a environment variable, of course... but even then the best default needs to be agreed upon.

[cmacq2]

This is a somewhat more polished effort based on the first:

• Add some heuristics to avoid the fiddling with the unsharing policy if it's not strictly required.
• Detect whether or not sudo and/or su are available, then use a fallback scheme (prefer sudo by default but fall back to su if available). I think this should resolve the sudo versus su sticking point of the original discussion.

[dlech]

I appreciate the idea here, but I'm still not keen on including this.

I've added a check for this in brickstrap.sh and added a bit to the readme in https://github.com/ev3dev/brickstrap/commit/f5b9bf0621b1aab8e66086c3c671428cbb12f0de.

The two things I don't care for are:

1. Since brickstrap is generally long running, it is highly likely that not only will you have to enter your password when it starts, you will also have to enter your password again when it ends, so if you run brickstrap more than once, this is not really saving you time vs. manually running sudo sysctl -w kernel.unprivileged_userns_clone=1 and sudo sysctl -w kernel.unprivileged_userns_clone=0 (and you can copy and paste from the brickstrap error message if you forget what the command is).
2. It hides what is actually be done from the user. Since this is a security issue, the user should know exactly what setting he/she is changing.

[cmacq2]

Fair enough. I don't really appreciate the security issue, in that there's functionally no difference between the user manually running the commands or manually using a fallback script that does it for them. There's something to be said for not doing more than necessary though, in case we get it 'wrong'.

So let's abandon this PR and consider the core issue solved/fixed.

By the way I've left a small review note on your commit.