Proper Plug config for unix.socket & Python subprocess module calls

snap
1

What’s the recommended way to configure the plugs for an app that uses Python’s subprocess module and communicates over unix sockets?

I’m running into the following firewall issues:

List Containers
Dec 21 15:48:17 dt kernel: [182748.273017] audit: type=1400 audit(1513892897.291:786): apparmor=“DENIED” operation=“connect” profile=“snap.lxdui.lxdui” name=“/var/lib/lxd/unix.socket” pid=4900 comm=“python2” requested_mask=“wr” denied_mask=“wr” fsuid=0 ouid=0

Network Manager Dec 21 15:46:44 dt kernel: [182655.923925] audit: type=1400 audit(1513892804.934:777): apparmor=“DENIED” operation=“exec” profile=“snap.lxdui.lxdui” name=“/usr/bin/sudo” pid=4930 comm=“python2” requested_mask=“x” denied_mask=“x” fsuid=0 ouid=0

The YAML file for the snap can be found here: snap file

2

I see you have lxd-support added to your plugs. This is for the LXD daemon, not for clients, so you can remove that. You do have lxd in your plugs, which is the correct one to access the lxd socket, but two things come to mind:

  1. Did you snap connect the lxd interface?
  2. The path your snap is accessing is a system path, not the path exposed by snapd, which is /var/snap/lxd/common/lxd/unix.socket.

Regarding the second denial, it’s trying to access /usr/bin/sudo which is not permitted because it isn’t within the snap world. I don’t believe you can escalate privilege within a confined snap anyway, so even if you bundled sudo into your snap and called that rather than the one in /usr/bin it will still fail (I think.)

3

Thanks for the response @lucyllewy. I’ll give classic a go and see how that goes.

4

Based on @lucyllewy’s feedback (thanks @lucyllewy!), I’m curious why you are going with classic confinement-- the only thing that seemed to be remaining was use of sudo, but if this is only about use of the lxd socket, users can either do sudo your.cmd or your users can add themselves to the lxd group (eg, on Ubuntu, sudo adduser <user> lxd.