Troubleshooting strict confinement

Afraid not. Same error, Failed to open /dev/EtherCAT0: Operation not permitted.

Any chance you actually need to run that as sudo?

That seems quite likely. I’ve tried to find information about running snaps as sudo but came up empty. Is there a quick way to test this?

Just run the app with sudo: sudo snapname.appname

Dumb question here, but I’ve been doing sudo snap start ... and sudo snap stop ....

sudo snapname.appname doesn’t work, I’m guessing due to daemon: simple. I can add another command without that and rebuild it to test?

Ah, it’s a service, no worries, that means it’s already running as root. Did you stop it before tweaking the profile, and then start it after reloading?

Yeah, I always stop and restart.

Huh. @jdstrand, does my apparmor syntax suck?

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. :smiley: 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.