No SSSD support in snaps (nsswitch.conf)

[ppd]

Given: A host that does user auth with SSSD (“LDAP”).
With base: core18 (or maybe in general?) /etc/nsswitch.conf is bound to something different than the host’s nsswitch.conf

E.g.

# snap
passwd:         compat extrausers

vs.

# host
passwd:         compat  systemd sss

Thus, within the snap context, getent passwd $USER will not succeed for non-local users.

Is that a supported use-case and should this work? Because if not, snapcraft-desktop-helpers and its “successor” the gnome extension (https://github.com/diddledan/snapcraft/blob/desktop-gnome-extension/extensions/desktop-common/desktop-init) can never successfully link remote users’ home directories into the snap. Quite problematic indeed for desktop applications.

Any suggestions or ideas on how to tackle this problem?

[chipaca]

I’m not sure I understand the problem. In what cases does snapcraft-desktop-helpers etc “link remote users’ home directories into the snap”?

[ppd]

Bad choice of words. desktop-launch softlinks xdg dirs for convenient access. I’m referring to https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L200 which gets its $REALHOME from here https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/init#L19

REALHOME cannot be deduced for users from sssd and is thus empty. You’ll find xdg dirs in your file chooser dialogs that do not correspond to those in the user’s home directory.

[ppd]

This old topic describes the root problem very well and presents a nice and easy test for user resolution failing for devices using SSSD.

SSS I have no name!

Hi! I noticed unexpected behavior when using any snap on a computer in the Windows domain (using SSSD service). In these cases, it is not possible to get the current user and group. This behavior occurs for any snap and in the case of libreoffice does not allow the completion of the installation process. Below the behavior for hello world: modolo@gsat019046:~/ansible$ snap run --shell hello-worl ... groups: cannot find name for group ID 265666619 groups: cannot find name for group ID 2656666…

An “okay” workaround in regards to the wrapper script is to deduce the “obvious” home dir from $SNAP_USER_DATA if getent does not return anything useful.

[chipaca]

have you looked at

Accessing unix users and groups from a strict snap

Probably the only way you’re going to reliably access exotic user/group tables in confinement would be via a proxy like nscd (or an equivalent like unscd). It looks like any of the interfaces that end up doing #include <abstractions/nameservice> should grant access to its socket. One such interface is network, which you might already be plugging. I realise that using nscd can have some drawbacks, but it might be the best option here.

?

[ppd]

@chipaca Absolutely phenomenal. That is indeed a good solution and works beautifully. Thank you very much. I had overlooked this topic as my search was not generic enough after a long day

For reference: Installing and running nscd or unscd on the host enables SSSD (and more) user resolution within the snap.

I’m wondering whether that could be a good addition somewhere in the docs…

[chipaca]

@ppd

I’m wondering whether that could be a good addition somewhere in the docs…

paging @degville to answer that one, as I don’t hold the docs in my head as well as he does.

[degville]

@ppd

I’m wondering whether that could be a good addition somewhere in the docs…

Good question - I think in the near future, this solution will be better referenced from the new Snapcraft build, debug and publishing docs roadmap, which we are working on and will complete soon. There’s troubleshooting for each phase and this will be a common question.

But it’s probably also worth mentioning in some of our environment variable documentation, where you might expect references to a user’s $HOME, for example.

I’ll make a note to do both of the above.

[jamesh]

It is probably of equal or greater interest to users rather than developers: a snap might work without issue on the developer’s machine, but fails for a user on a machine configured to use LDAP.

It’s not really something the snap author can handle from their side of the sandbox.

[ppd]

Yes, that is strictly a user thing. In a perfect world, the user would be informed upon installation or running of a snap that the current user cannot be resolved and a solution would be proposed.

[nsg]

I was affected on this on my work computer using sssd to talk to the corporate AD domain. I have found several snaps that completely breaks for me because of this. The internet is quite clear that you should absolutely not use sssd and nscd in parallel to cache passwd entries. I installed nscd anyway with passwd cache enabled (enable-cache passwd yes) the snaps work but I get this in the sssd logs:

aug 18 09:20:50 myhostname sssd[20780]: NSCD socket was detected and seems to be configured to cache some of the databases controlled by SSSD [passwd,group,netgroup,services]. It is recommended not to run NSCD in parallel with SSSD, unless NSCD is configured not to cache these.

I will try to investigate a little closer why nscd is not recommended and see if It’s an acceptable workaround for me. But overall, I like to get some feedback if there is a better way today considering the age of this issue and the fast moving pace of development in the snap ecosystem.

[jamesh]

The main reason is that both sssd and nscd cache user information, so stacking could out dated results being cached longer than expected. Imagine you request info that is cached in sssd just before it is set to expire. That might now be placed in nscd’s cache and be considered fresh past when sssd believes it is outdated.

You could minimise this by cranking down nscd’s TTL values to reduce the window.