In Bootstack team at Canonical we are working on a snap for managing our clouds built by Juju. This snap needs to access unix users and groups on the host machine. At the moment we are not able to do this using strict confinement.
Could you please show me the best practice to do this from a strict snap?
~$ snap install test-snapd-tools
test-snapd-tools 1.0 from Canonical✓ installed
~$ test-snapd-tools.sh
Launching a shell inside the default app confinement. Navigate to your
app-specific directories with:
$ cd $SNAP
$ cd $SNAP_DATA
$ cd $SNAP_USER_DATA
bash-4.3$ grep lxd /etc/passwd
lxd:x:999:100::/var/snap/lxd/common/lxd:/bin/false
bash-4.3$ python3
Python 3.5.2 (default, Nov 12 2018, 13:43:14)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import grp
>>> grp.getgrnam("lxd")
grp.struct_group(gr_name='lxd', gr_passwd='x', gr_gid=999, gr_mem=['john'])
>>> grp.getgrnam("lxd").gr_mem
['john']
>>>
I can confirm that your tests is working for groups specified in /etc/group
The same test would fail if you are using a group database in /var/lib/misc/group.db
And your /etc/nsswitch.conf has the following configuration:
passwd: compat db systemd
group: db compat systemd
shadow: compat db
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
You are right that /var/lib/misc/group.db would be from the snap and not the host because /var/lib/misc is not bind mounted from the host into the snap. This would require a change to snap-confine. I guess you are using ldap with cached credentials? Can you describe the environment more?
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.
The nscd daemon listens on the unix domain socket /var/run/nscd/socket. If that socket exists, glibc will send queries there instead of using /etc/nsswitch.conf and the associated plugins.
That socket should be visible within the snap sandbox, and accessible if you plug the network interface (among others). The actual database lookups would then occur outside of the sandbox, so should be able to use plugins that are non-functional under confinement.
Nscd has a reputation for being a bit unstable (which is one of the reasons for unscd exists), so I don’t know if it is something you’d want to consider for your team. But this is probably the kind of thing necessary to handle e.g. LDAP, winbind etc account databases.