FYI when deciding on an ID range: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1707645. It seems that while they are supported, there may be some corner cases (like lastlog) where software is written to efficiently account for them.
@jdstrand Thanks for putting this together! It does capture what we discussed well.
I’ll follow up with proposals for some of those questions soon.
I don’t even have this module in Fedora in the repositories, much less enabled as a source in nsswitch.conf. A quick lookup indicates this was a module built several years ago by someone in Debian and it lives pretty much exclusively in Debian/Ubuntu archive. The only external source we have supported out of the box is the
sss NSS module (which, because it’s SSSD, does actually support multiple backends and such, but there’s nothing we have that can interface with it right now).
That is useful information. Thankfully, the extrausers module is only required in the core snap for Ubuntu Core (ie, not cross-distro). As such, it can live in the core snap and base snaps (eg, ‘Fedora base’) don’t have to worry about it. Only if someone wanted to create an alternate core snap based on a different distribution would extrausers (or an alternative) need to be considered. It would even be possible for that alternate core to skip the need entirely and make the passwd and group database read/write.
Only when making all of core read write else UID/GID filesystem mappings will eventually fall apart …
My point was that would ultimately be a decision for whoever was putting together ‘Alt Core’ devices, not that it would be a recommended thing to do.
I have a very strange behavior with my machine that is in AD (SSSD). For example, you can not list the files using hello-world.sh.
I have verified that it is not possible to consult domain users!
bash-4.3$ getent passwd modolo bash-4.3$ getent passwd root root:x:0:0:root:/root:/bin/bash
Today, domain users need the ‘network’ interface and the hello-world snap does not ‘plugs: [ network ]’.
To make this work in the default template (arguably something that should be done), fine-grained network mediation in AppArmor (future work) might be able to allow name lookups. Alternatively, an nss module could be made available to snaps (eg, a bind mount) that could talk to an out of process proxy on the system to do the lookups on behalf of the application.
We could also do something similar to what I proposed for NFS /home: make a core config that unconditionally allows the network interface/apparmor nameservice abstraction. I wonder how useful this (and NFS /home) would be per-snap rather than global config…
The lack of possibility to list users of the domain prevents me for example from completing the installation of snap libreoffice!
On the same machine if I authenticate myself as a local user, I can fire the libreoffice (snap run libreoffice) and complete the installation!
I believe the libroffice needs to check local folders (~ / .config) that are not available since the permissions become wrong.
@niemeyer - I noticed the topic title changed to ‘multiple users and groups in snaps’. This title doesn’t cover all four use cases and is somewhat confusing. The use case are (taken from the introduction):
- adding system users/groups https://launchpad.net/bugs/1606510
- supporting device access via ACLs for granting access of devices to (non-root) users. https://launchpad.net/bugs/1646144
- per-snap opt-in users to support things such as privilege dropping/separation within snaps. https://launchpad.net/bugs/1619888
- Supporting uids/gids in chroot environment
The bug links above are broken, the right links are:
Just to add some user feedback to this point, the key thing missing here for us is use case 3.
Various servers will just point blank refuse to run as uid 0, with an explicit check in the codebase. Examples include postgresql and squid, both exactly the kind of software you are likely to want to embed in a snap.
The only option for us right now with postgresql is to src patch those checks out, and compile custom postgresql binaries to ship with our snap, something we are currently not willing to do (our build times would skyrocket, amongst other issues).
We would be ok with running as one of the ~20 or so default users (daemon? www-data? nobody? proxy?) in this case, but no filtering on setuid makes this impossible for a strictly confined snap.
Any progress or changes for this?
How does this design relate to an app like syncthing which needs per-user services that are run as individual users already on the system, and not as root? In this case we wouldn’t be able to enumerate ahead of time in the snapcraft.yaml what users to run as, so I’m not sure if any of the 4 use cases presented would solve this problem. Perhaps this is entirely orthogonal to the design here…
Note that the associated launchpad bug for this particular use case is here : https://bugs.launchpad.net/snappy/+bug/1613420
in that usecase you would likely use a session systemd unit (which only works on newer systems where systemd manages the desktop session) … i think there was a topic somewhere in the forum about autostarting session related services (which would automatically run as the logged in user)
alternatively you could start it as dbus session service … that would run as the user as well …
@dmitriis Still on the roadmap, but not in progress right now as we have a few high-cost features in progress. We will evaluate again at the end of the cycle in October.
@ijohnson It’s not quite related. What you refer to may already be achieved with something like the autostart feature, while the ideas covered in the topic here are more about multiple users inside the snap proper.
FYI, there is some information for what this will most likely look like for use case 2 (device acls) in HDMI Output with ffplay.
I have still this problem for my CUPS snap: User authentication in snapd (pam mediation). Is there any progress here which could help me solving this problem?
Note: the currently implemented parts seem to be documented here: System usernames