Yeah, I always stop and restart.
I have a concern that there might be an issue with the fact that some of the dependencies built outside of the snap reside in my home folder. Ignoring for a moment whether this is the best practice, is there a folder that I could try using that will be accessible from both inside the snap and out without extra configuration? I’ve found that /var/snap works, is that a good path?
Try the following:
snap install hello-world
Then run “hello-world.env” that prints out all environment variables… typically you want to use $SNAP_DATA for daemons and $SNAP_USER_DATA for applications executed by users…
Hey @ogra, glad to have more brains on this. 
That’s not going to help here, though. Let’s forget about my last question regarding the dependency paths for now, I think it’s fine.
Did we get confirmation about whether /dev/EtherCAT[0-9]* rw, was the right command for testing the change to the apparmor profile? I get the same error with and without and in neither case do I see an explicit DENIED from apparmor.
Anything else we can think to try?
You could, if you really want to get into the nitty gritty guts of things, try stracing your app and trawling through the copious spew to see if anything seems amiss. Though to fully understand such a stream of consciousness takes a lot of effort in trying to discern what each entry is showing your app is doing, why, and whether it is normal or abnormal.
This is great, I immediately found a few missing files related to my really troublesome dependency. I’m going to keep going down this path. Thank you for suggesting this!
No. As mentioned elsewhere, there were no denials so it is something outside of AppArmor.
1 Like
@cg-bbi what are the permissions of /dev/EtherCAT0? Starting to wonder if that’s where the DAC override stuff is coming from.
I think I got it. It needed a udev rule in addition to the AppArmor rule. I tested manually and it’s starting, but I need to plug it into the robot to see if we’re good.
If this does work, I’ll see if I can wrap up the custom interface. Are there docs somewhere detailing the process of having my snapcraft dev box use my forked snapd so it can test the interface?
It’s actually quite non-trivial, assuming things haven’t changed much since I worked on it. It re-executes itself from the core snap, and it’s not possible to turn that off completely. Making sure the apparmor rule works via the method given above and writing good tests in snapd is probably enough for a relatively simple interface like this.
I see. Alright. I’ll finish the interface once I can confirm that everything is working with my hacks in place.
I now have everything starting without clear errors or DENIED messages from AppArmor, but my EtherCAT control messages and feedback appear to be getting lost. snappy-debug logs messages from Seccomp status that our control package (which is responsible for EtherCAT communication) is calling setpriority. It recommends I add browser-support or process-control plugs. I added process-control, manually connected, but no change.
I assume that snappy-debug is logging this because that call is failing, and considering it’s coming from the ROS package responsible for the feature that is failing, I’m hoping that correcting this is the last thing I need to get this working. If connecting process-control doesn’t solve it, is there another established way around this?
To be clear, when you say “no change,” are you saying that communication still doesn’t work, or snappy-debug is still complaining about it?
Communication still doesn’t work and snappy-debug continues complaining.
How odd. Did you restart the daemon after connecting the interface? process-control adds blanket permissions to use setpriority.
Yes, I did. Just to confirm, I’m connecting it using:
sudo snap connect my-snap:process-control core:process-control
Yeah that’s fine. You can probably leave off the core bit though, for future reference:
$ sudo snap connect my-snap:process-control
@jdstrand any idea what’s happening here?
Unlike apparmor, seccomp policy changes cannot be applied to a running process so depending on the ordering of events, the connected process-control policy might not have been in place. The other option is the ‘process-control’ was added to only one command in the snap, and another command (also) needed it.
If after considering the above, please paste the snappy-debug denial and the policy in /var/lib/snapd/seccomp/bpf/snap.your.command.src that is being denied.
This is the error being logged.
= Seccomp =
Time: Jan 23 17:00:34
Log: auid=1000 uid=0 gid=0 ses=1 pid=3447 comm="control_package" exe="/snap/my-snap/x1/opt/ros/kinetic/lib/control_package/control_node" sig=31 arch=c000003e 141(setpriority) compat=0 ip=0x7f09618d4d27 code=0x0
Syscall: setpriority
Suggestion:
* add one of 'browser-support, process-control' to 'plugs'
Can you also paste/attach the output of snap interfaces and if process-control is connected, paste/attach /var/lib/snapd/seccomp/bpf/snap.<the command that triggers the denial>.src?