I suspect it is actually the syscall filter that is blocking this. Using the lpadmin user is a variant of use case ‘1’ of Multiple users and groups in snaps (cc @pedronis). In this case, it sounds like your snap is trying to use an existing lpadmin or adm group on the system. This is currently unsupported.
We can possibly update the slot policy for the snap to do a getgrent() and add policy if one of these groups exists, but that is quite unusual for snaps and likely needs design. AIUI, you have designed your snap to have certain processes drop to snap_daemon and you don’t want them to be able to access these files. You want an additional group (ideally one that is widely used cross-distro) so that non-snap-daemon users that belong in this group can access the files, is that right? If so, @pedronis, this is similar to the microk8s case.
@till.kamppeter - today, sudo is needed to access those files.