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?
Needed some space from this so I can come back with a clear head. I worked out of the office today and didn’t have access to the problem system, so I’ll get you that info tomorrow. Appreciate your help.