At this moment I’m focusing on mosh which happens to complain:
Can't load '/usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so' for module IO: /usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so: failed to map segment from shared object at /usr/lib/x86_64-linux-gnu/perl-base/XSLoader.pm line 70.
but IO.so is present at /snap/irc/current/usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so.
Importantly, it will recommend that you install ‘snappy-debug’ which can be used to suggest various things (eg, interfaces to plug, things to change in your snap, etc).
That said, based on your denials, your snap is attempting to:
use the mknod syscall (scmp_sys_resolver 133)
For the first, this should be resolved in snapd 2.25 where we are using seccomp arg filtering for the mknod syscall to allow creating files, sockets and pipes (but not block or character devices)
For the second, you reference you are expecting your snap to use /snap/irc/current/usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so, but the denial is for /usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so. This indicates a problem with your snap not finding the proper IO.so. You may need to set PERL5LIB appropriately or otherwise adjust your snap so @INC will find your module. A snapcraft developer may be able to help further.
Interestingly, I expected /usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so to be allowed by the apparmor policy via the /etc/apparmor.d/abstractions/perl include file. It has:
This is actually fixed in trunk (and therefore the upcoming snapd 2.27) for S_IFREG, S_IFIFO and S_IFSOCK in the default template. If your snap is trying to create block or character devices, we’d need to gather specifics on the devices in question and determine the best path forward.