Restore creation of $SNAP_USER_DATA

[zyga]

This patch restores creation of SNAP_USER_DATA directory. This was a regression of functionality that occurred because the new code path in snapd that does the same thing is not active yet (it depends on snap-exec).

The fix comes with spread tests that should reliably work even when snap-exec is in use.

Fixes: https://bugs.launchpad.net/snap-confine/+bug/1612120

[mvo5]

I was initially wondering if we need extra validation here, but I think we don't because privs have already dropped when mkdir is called.

[mvo5]

We might check for ".." in the path though and disallow that.

[zyga]

We might though snap-confine is already confined with apparmor so (at least where apparmor is used) this is not critical. I will land this and follow up with a small patch to check for ... Thanks for spotting this.

[mvo5]

Looks good, thanks for the tests!

[mvo5]

Sorry, but this appears to cause a regression with the apparmor rules on ecryptfs.

[zyga]

I will try to come up with a one-time fix by testing locally with encrypted home directory but we should investigate how to support that in spread.

[mvo5]

👍 looks good, will test in a bit

[jdstrand]

I am not a fan of this change because I think it is papering over the larger problem of using sudo with snap commands and the fact that it is creating directories with root:root permissions in the user's home directory. This feels very wrong and causes lots of pain for users when they use the command under sudo and it later fails when not running under sudo.

That said, the architects have not taken a stance on this issue yet and the current implementation dictates that it should work, so these rules are required.

+0 (as in, I won't block this commit, but I do not approve of the changes)