TL;DR: Makes sense. Happy for the fallback, is it possible you could suggest some code that works? Only asking because there's basically no way I could test that setup 😄

Some comments inline for other options, not sure they invalidate what you're asking for, but FYI.
On Jun 3 2021, at 11:35 am, Douglas Paul <doug-inks@bogon.ca> wrote:
So, the first thing I tried is to add the following in the snap's
apparmor profile:

#include <abstractions/nameservice>
#include <abstractions/bash>

And this got rid of the bashrc access errors (which likely aren't fatal,
anyway), and I could get a proper result with this:

aa-exec -p snap.inkscape.inkscape getent passwd $UID

So, I thought this would work. However, it still doesn't...

Generally speaking you probably don't want to edit those as they'll be regenerated on the next update. For tuning apparmor (and this will be for all snaps, debs, etc) you want to use /etc/apparmor.d/tunables, and specifically in this case the home file for the directories. That'll change what is home for apparmor, and so then your snaps will get access to those directories. You should also be able to add stuff for getent, but I'm not sure exactly how that should work.

With careful use of ctrl-Z and attaching strace (since it seems you can't strace directly), I was able to see that the /etc/nsswitch.conf being used by inkscape is coming from inside a chroot or otherwise remapped by snap, and it does not use the system /etc/nsswitch.conf.

To strace a snap you can use the parameter on the run command. So: snap run --strace inkscape

All this to say -- would it be possible to have a fallback in the environment to use the old behaviour (was it to use $HOME as REALHOME?) in case the calls to getent fail? Or, at the least, it should be documented that using nscd/unscd is required when a different nsswitch.conf configuration is used.

+1, this is the script that needs to be modified: https://gitlab.com/inkscape/inkscape/-/blob/1.1.x/snap/local/scripts/inkscape-variables
Ted