Snap-confine issues - - more 'things changing' without my doing things

LXD
1

I have worked a little on trying to access previously setup containers (on Debian stable setup using snapd).
So I’m trying to find some way of using btrfs to access these containers.
Today I’m wanting to give up on waiting for some assistance on this (waiting for a while imo) and so I want to just set up some more new containers and then move things for only one of the containers but then I could get working on the business project that was setup on that particular container.

So I get this:

memyself@debianserver:~$ lxc list
snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

I’m not sure what this even means!
How to I lull the dragons so that I can get some work done?

TIA

2

Reading this page:
https://stgraber.org/2017/01/13/kubernetes-inside-lxd/

my issue has been run into before.
Is there a fix as reading:

https://github.com/snapcore/snap-confine

indicates that the fix given in the first mentioned page won’t be working as snap-confine is now wrapped inside snap itself.

memyself@debianserver:~$ snap --version
snap 2.29.4.2
snapd 2.29.4.2
series 16
debian 9
kernel 4.9.0-5-amd64

Am presently doing a system upgrade to kernel 4.9.0-6 also.

3

That error is coming directly from snapd unfortunately, I’d recommend filing a bug against snapd in the Debian bug tracker or open a forum thread at https://forum.snapcraft.io.

Until then, I suspect running the LXD client as root may get you out of that problem?

The snapd foks are more likely to be able to root cause this than I am, but to me it sounds like some apparmor interaction which is odd given that Debian stable shouldn’t have it enabled.

4

Sorry - - - that isn’t going to help either.

root@debianserver:/# lxc list
bash: lxc: command not found

Somehow on debian things have to happen on the user level, not on root.
I’m not sure why this goes like this.

5

Ah, I suspect root simply doesn’t have the snap binaries in its path.
Does running /snap/bin/lxc as root work?

If so, you’d need something like this in root’s bash profile:

export PATH=/snap/bin/:${PATH}
6

Thanks - - - so I can get lxc commands working now while I’m in root but not when I’m user which is the opposite of how its been before.
Somehow I"m not supposed to have apparmor installed yet when I tell apt to install snapd it drags along apparmor and a few other packages.

Total weirdness!

Is it safe for me to set up more containers and start working in them?
By doing so will I be compromising those new containers permanently?
What about the existing containers?

Edit for further information.
now working as root I get:
root@debianserver:/# lxc storage volume list lxd2
±----------±------------------±------------±--------+
| TYPE | NAME | DESCRIPTION | USED BY |
±----------±------------------±------------±--------+
| container | my-debian | | 1 |
±----------±------------------±------------±--------+
| container | my-debian-sid | | 1 |
±----------±------------------±------------±--------+
| container | my-debian-testing | | 1 |
±----------±------------------±------------±--------+
| container | my-ubuntu-trusty | | 1 |
±----------±------------------±------------±--------+

previously the same command gave:

memyself@debianserver:/$ lxc storage volume list lxd2
±----------±-----------------------------------------------------------------±------------±--------+
| TYPE | NAME | DESCRIPTION | USED BY |
±----------±-----------------------------------------------------------------±------------±--------+
| container | my-debian | | 1 |
±----------±-----------------------------------------------------------------±------------±--------+
| container | my-debian-sid | | 1 |
±----------±-----------------------------------------------------------------±------------±--------+
| container | my-debian-testing | | 1 |
±----------±-----------------------------------------------------------------±------------±--------+
| container | my-ubuntu-trusty | | 1 |
±----------±-----------------------------------------------------------------±------------±--------+
| image | 220d6080fba7be9fe9d00dfea2fa066889c5a0ba324d02303efbb87a86fc53b6 | | 1 |
±----------±-----------------------------------------------------------------±------------±--------+
| image | 3698c5e8b4004937115a368c54135e03f4c70950d08970180f642f45686d32d3 | | 1 |
±----------±-----------------------------------------------------------------±------------±--------+
| image | 832d62b3d3ec97ab841b5fd44b013d6818f917b0fa98bf1b9fb5e098160fa87e | | 1 |
±----------±-----------------------------------------------------------------±------------±--------+
| image | 9b1a28ea0b1c89468433fc5636cda9abd9030e43abdac12d825ca141c56bea81 | | 1 |
±----------±-----------------------------------------------------------------±------------±--------+

7

Yeah, everything should be fine except for running snap commands as non-root which seems broken on your system for some reason (you’ll have to file a bug against snapd to figure that one out or contact them on their forum).

The reason why those images disappeared from your volume list is probably because the images have since expired, causing LXD to automatically remove them.

8

Thanks for the information.
Filed a question on their forum.
Haven’t seen a way of filing a bug yet - - - think I should look for it. Thanks for the idea.

9

https://launchpad.net/snapd/+filebug

10

Thanks - - filed it as a security issue as well

11

OK - - - a not so simple process with a lengthy series of interaction but the end result was that snapd seems to be behaving itself - - - for now.

Any way to stop snapd from modifying itself?
IIRC I allowed automatic updates in my setup - - - should I be looking at changing that?

Am marking the issue as solved.
Thanking Monsieur Stephane (needs an accent grave I believe on the last vowel Linux sin’t really multilingual!!) for his pointers and assistance!!