Accessing unix users and groups from a strict snap

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?

Is there any plug that allow us to do this?

Feel free to hit me on IRC, peppepetra.

/etc from the host is what is in the snap in strict mode. What specifically do you mean by ‘access unix users and groups on the host machine’?

I would like to access Unix group database using the module grp https://docs.python.org/2/library/grp.html

Like this:

grp.getgrnam(unix_group_name).gr_mem

At the moment this only works if I use:

confinement: classic

in the snapcraft.yaml.

Thank you for the help.

It does work:

~$ 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']
>>> 
1 Like

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

netgroup: nis

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?

Yes exactly, we are using userdir-ldap with cached credentials.
In /var/lib/misc we have group.db, passw.db, shadow.db and authorized ssh keys.

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.

Could you please clarify how you think nscd should be used?

Thank you.

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.

Thank you for the clarification I will test it this solution.

I can confirm that installing nscd on the host gives to the strict snap access to the group database configured outside of the snap sandbox.