Hello,
I recently had a machine running Ubuntu auto-update its snap to version 1.1. In this version, there seems to be a new mechanism to determine the default config path using getent that is not functional on my system.
Some particularities that I have: 1) passwd / groups of users come from a Samba AD using sssd 2) home directories are mounted on NFS
The problem that I see is that the REALHOME variable is not set correctly, so it tries to look for the configuration in /.config/inkscape.
This is what I see when launching:
==== $ LANGUAGE=en_CA:en inkscape /bin/bash: /home/doug/.bashrc: Permission denied /bin/bash: /home/doug/.bashrc: Permission denied /bin/bash: /home/doug/.bashrc: Permission denied Unable to init server: Could not connect: Connection refused ** Message: 08:43:39.229: Cannot create profile directory /.config/inkscape. ** Message: 08:43:39.229: Inkscape will run with default settings, and new settings will not be saved. ** (inkscape:3501254): WARNING **: 08:43:39.395: Could not create directory '/.config/inkscape' ** (inkscape:3501254): WARNING **: 08:43:39.396: Could not create extension error log file '/.config/inkscape/extension-errors.log' ** (inkscape:3501254): WARNING **: 08:43:39.476: Fonts dir '/.config/inkscape/fonts' does not exist and will be ignored. ====
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...
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.
It looks exactly like this issue:
https://forum.snapcraft.io/t/no-sssd-support-in-snaps-nsswitch-conf/10412/12
It seems like the only way around this problem is to use NSCD as a proxy, which is generally not recommended, it seems, but might be the only choice I would have. (Using unscd does seem to work, even with 0 cache ttls -- so I think this should be safe)
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.
Thanks,