This is my first attempt to use LXD on an Ubuntu host, and I’ve already run into a bit of strangeness perhaps someone can explain. On enabling the LXD service and creating an Ubuntu 15.04 container:
This seems unnecessarily presumptuous. Most users of the system log in using an AD account, the local accounts are the administrative user (cnsit) and a couple of student assistants (matanb, rmccool) who have been assigned projects on this particular workstation. Oddly, matanb has 2 entries(??) and the assigned uid’s seem really random. Since the local accounts won’t even be using the container(s) on this machine, I’m unclear on why this automatic population of /etc/subuid is occurring. I’m still trying to puzzle through the authorization system, so am asking questions about things that don’t make sense to me.
However, all those users were added long before the LXD service was turned on? So maybe the inclusion is not based on whether or the service is running? And I guess it’s not idempotent, as it’s possible I added the local user matanb twice, removing him the first time for reasons I don’t remember. Still very confused about how it’s choosing UIDs and why lxd and root are both in there as 362144, or why lxd needs an entry at all, for that matter.
Yeah, none of this is managed by LXD or caused by LXD at all.
It’s normal behavior for shadow (useradd, usermod) on modern systems at least on Ubuntu.
What may have caused the change is LXD depending on the uidmap package which may have bootstrapped the subuid/subgid files and caused shadow to start adding entries.
In any case, it’s perfectly fine for you to go mess with subuid/subgid in whatever way you want. LXD only cares about the root entry, the lxd entry is there only for tracking purposes.
One complication I’m worried about is compatibility with directory-based authentication. On a lot of our systems (and more, moving forward) we’ve switched to using the University’s Active Directory system for authentication; mainly because everyone is in it automatically and they have a whole system for managing and securing the passwords. The only downside is that SSSD has been kind of flaky (although starting to stabilize) Those UIDs ending up being really large numbers, but once various systems start mapping into that address space I start to worry about UID collisions; especially since we still end up using local groups, etc… For example, my current LXD project involves creating an Ubuntu 15.04 compute environment for a user that logs in using her AD credentials. I need to set it up so that she can mount her home directory into the container, but would prefer for her not to have root access in the container, as this generally ends tragically. At the moment I’m trying to puzzle through how to facilitate this.