userns remapping fails on externally authenticated Linux host...

[InfoSec812]

My laptop uses samba/winbind authentication, so there is no passwd entry on my machine for my user. This would be similarly true on an LDAP or NIS authenticated machine. When I try to use --userns-remap=<myuser>:<mygroup>, I get the following error:

Error starting daemon: Error during uid lookup for "<myuser>": no matching entries in passwd file

I would propose that you should use getent passwd and getent group instead as it would supply details for user accounts which may not be local.

[InfoSec812]

$ docker version
Client:
 Version:      1.10.0
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   590d5108
 Built:        Thu Feb  4 18:41:30 2016
 OS/Arch:      linux/amd64


$ docker info
Containers: 16
 Running: 0
 Paused: 0
 Stopped: 16
Images: 150
Server Version: 1.10.0
Storage Driver: btrfs
 Build Version: Btrfs v4.0
 Library Version: 101
Execution Driver: native-0.2
Logging Driver: json-file
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 4.5.0-040500rc1-generic
Operating System: Ubuntu 15.10
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.53 GiB
Name: laptop
ID: N2ND:QSPH:7TYJ:P2WK:LJCB:MB4H:763X:7Z23:PNXT:GWHZ:LNGN:LWF6
WARNING: No swap limit support

[estesp]

Thanks for the report--not sure we had thought about using getent as a system utility versus the libc getent(); we've purposely (historically) stayed away from resolver/nss calls in libc because it then forces you to dynamically link, and for quite a while Docker was a statically linked binary (and can still be built as such). But, shelling out to getent is another option that skirts that issue.

On a separate note, given one of the reasons we are looking up the user is for the next step: reading the /etc/sub{u,g}id files to parse the mappings assigned to your user. Do those files exist on your install? If you didn't go through a standard user creation scenario I'm curious if you don't have uid/gid map ranges assigned to your user either.

[InfoSec812]

I was unaware of the need for those additional files... Is there any documentation which explains how they are used?

[estesp]

Yes: https://docs.docker.com/engine/reference/commandline/daemon/#daemon-user-namespace-options

I can point to a longer discussion where we were convinced by the main author/maintainer of user namespaces in the Linux kernel that this is the right model to use, as this is the accepted way for Linux distros to manage uid/gid map allocation. The format is simple enough that an administrator can create them by hand if necessary, if your distro tooling doesn't support auto-generation, or user creation wasn't performed on the system itself.

[InfoSec812]

NVM, I found it in the man pages... You are right. Currently, pam_cifs does not populate those files with samba user information. I will see if I can submit a patch to allow for that on the PAM project.

[cpuguy83]

👍 Thanks @InfoSec812

[digi691]

I ran into this issue the other day trying to setup a user that is provided by SSSD.

@estesp,
In regards to setting up /etc/sub{u,g}id; I'm using a configuration management utility to manage and populate these files.

My current work around for a user that is provided by SSSD is to add the user as local user first with matching gid/uid in LDAP, and then start SSSD. It would be great if Docker actually tried the other resolvers provided by nsswitch.

[estesp]

@digi691 one of the issues with Docker actually using glibc-based nsswitch capabilities is that this breaks the ability to statically link Go binaries; well more clearly, it requires some caution as you can see from that thread of discussion in a golang issue.

Of course, distro versions of Docker tend to be dynamically linked now, as opposed to earlier releases that were almost always statically linked. Because of the above issues, libcontainer implemented it's own user/group lookup using direct parsing of the /etc/{passwd,group} files to get around being linked dynamically to glibc libraries (and then having the issues noted in these other conversations).

Maybe that can be revisited given the comment about most deliveries being dynamically linked now, but I think a more complete review of all the various binaries and how they are delivered would have to be done before switching to the glibc-based calls to query user/group info, which would honor nsswitch settings.

[InfoSec812]

@estesp But as commented earlier in this thread, docker could just call the getent command instead of calling through glibc.

[estesp]

Reasonable thought--for some reason I had glossed over that as referring to an API call, not /usr/bin/getent. I'll look into this a bit

[thaJeztah]

ping @estesp were you still working on this?

[estesp]

@thaJeztah yes, on my list. Let me see if I can get a WIP PR/branch together as I will need some user testing as I don't have a setup with external LDAP or other externally provided user/group database.

[estesp]

I have attempted to solve this via PR #27599. I do not have a system capable of testing this, although I have been able to test that the calls to getent work appropriately (by forcing that path specifying users and groups that don't exist locally).

Is anyone on this issue stream able to test this PR and validate? That would be awesome!

[dragon788]

So in testing this recently I ended up having to put the specific UID returned by id -u through SSSD rather than it automatically falling back to getent and finding my username automatically. Not sure if it is directly related but there seems to be something funky happening during the lookup.