Comment 44 for bug 1628289

On Sat, Nov 18, 2017 at 11:25:49PM +0300, Marat Khalili wrote:
> > The problem in your case is that you're trying to get this to work with LXC rather than LXD.
>
> Should I understand it as snapd is not currently supported under LXC? No way to reproduce manually in LXC whatever LXD does?

We don't directly support it in LXC, no.

If you want to replicate what LXD does, you're going to need to:
 - Bind-mount /dev/fuse
 - Allow /dev/fuse to be written to by the container
 - Create a new apparmor namespace and load the base apparmor profile into it (lxc-container-default in lxc's case)
 - Set lxc.aa_profile to point to that namespace
 - Add some kind of hook to cleanup that namespace when the container exits

> > I'd very strongly recommend against anyone using the configuration above with LXC as the lxc.aa_profile=unconfined [...]
>
> Obviously not the best solution security-wise, but doesn't snapd provide its own level of isolation? It shouldn't be worse than running snapd on host, for people choosing not to rollout LXD?
>
> (Sorry for being increasingly off-topic, but currently Google brings people wishing to install e.g. nextcloud in a container here.)

Setting aa_profile=unconfined allows your container, to load, unload and
modify any apparmor profile on the host.

That means it can interfere with any process running on the system,
crossing container boundary. It can prevent random system processes from
functioning by loading new profiles or altering existings ones, ...

Even if all workloads are trustworthy on your system, you then have the
problem that only a single container can run snaps as running multiple
containers with snapd or having snapd run on the container and in the
host will result in apparmor profile conflicts with global policies
being modified every time snap-confine runs in one of the containers or
host.

Stéphane