Issue with Inkscape 1.1 snap and REALHOME / getent
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,
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/inkscap... Ted
On Fri, Jun 04, 2021 at 11:24:32AM -0500, Ted Gould wrote:
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 😄
Sure, I can take a look to put together a patch. I have close to zero experience with snaps (as you could probably tell with my manipulation to strace it :) -- thanks for the tip), but I'll dig up some build instructions and give it a go.
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.
Right, I had a feeling that would end up being clobbered. Fortunately, those modifications don't seem to be necessary when running with unscd. Strangely, I have no problem accessing anything in /home from Inkscape, but it is just the bash subprocesses that complain about not having access to ~/.bashrc ...
+1, this is the script that needs to be modified: https://gitlab.com/inkscape/inkscape/-/blob/1.1.x/snap/local/scripts/inkscap...
Thanks, I'll start there.
On Jun 6 2021, at 8:27 am, Douglas Paul doug-inks@bogon.ca wrote:
On Fri, Jun 04, 2021 at 11:24:32AM -0500, Ted Gould wrote:
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 😄
Sure, I can take a look to put together a patch. I have close to zero experience with snaps (as you could probably tell with my manipulation to strace it :) -- thanks for the tip), but I'll dig up some build instructions and give it a go.
Awesome, I'm "ted" in the devel channel if you get stuck. Ted
participants (2)
-
Douglas Paul -
Ted Gould