-
Notifications
You must be signed in to change notification settings - Fork 18.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docker containers can conflict with users on host system in Linux 3.15 #6345
Comments
As I started this discussion on the mailing list, I would like to add a few points: I thought this was kernel independent, but @BlueLaguna seems to be correct: this is probably 3.15 related. The reason I thought I got this on 3.13 was because we were in the midst of changing kernels. I now cannot replicate this on 3.13. In my case the behaviour changed if mysql-server was installed or not in the HOST machine. MySQL server Not installed: no PAM problems. Installed: did not work It seemed a PAM issue (which chfn complaining). |
I'm actually can't add any user, not only existing on host machine. I'll retry with 3.14 soon. |
This is definitely an odd one. Does it do the same thing when you use |
@tianon No, useradd works fine |
I've been looking through the Kernel changelogs and perhaps this commit might be relevant: |
Seems strange, it works for me on my work machine with |
Same on 3.15.1 |
Confirm, that all works fine with 3.14.8 |
I've tried to revert this patch https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=543bc6a1a987672b79d6ebe8e2ab10471d8f1047 and it didn't fix the problem. If you want to try to revert the patch, you'll have to revert it by hand because the code has been changed since this patch was merged and it won't get reverted cleanly. |
Also, to be sure, what graph driver are you guys using? Mine is btrfs. |
Hello till this is fixed simply use a bash alias to re route the adduser command like this +RUN alias adduser='useradd' && DEBIAN_FRONTEND=noninteractive apt-get -y install mysql-server pwgen |
Two possible clues:
|
@jpetazzo I don't use apparmor or something like this. |
none of these breakages happen on boot2docker 1.1.0 which runs Linux 3.15.3 - in case this (and its config) give you ideas.... |
I'll try |
Still not working with |
3.15.4 same problem |
I use this to workaround the issue while it gets fixed:
Looks like anything related with modifying users (chpasswd, passwd, chfd, useradd) raises an error. |
If you're not building a container, you can use something like this on the host machine: sudo nsenter --target $(docker inspect --format {{.State.Pid}} $YOUR_CONTAINER_ID) --mount --uts --ipc --net --pid /bin/bash Then you can use |
The problem I reported in #7123, which may be the same as the problem under discussion here, appears to have been caused by kernel commit 33faba7fa7f2288d2f8aaea95958b2c97bf9ebfb (https://github.com/torvalds/linux/commits/33faba7fa7f2288d2f8aaea95958b2c97bf9ebfb). From v3.15, running 'git revert 33faba7' and dealing with the resulting conflicts results in a build that operates correctly. I haven't actually taken a close look at what the code does or why it actually fails. |
Specifically, this check is failing in kernel/audit.c:
|
@larsks Oh wow, great work! I don't think any of us would've been able to come up with any of this on our own :-) 👍 |
I've spoken with some of the audit subsystem folks, and the general consensus is that if you want to write audit messages you need to retain CAP_AUDIT_WRITE. The fact that it worked previously was just luck due to insufficient checking in the kernel. If Docker is explicitly dropping capabilities in containers, the CAP_AUDIT_WRITE capability should be retained. |
This is probably obvious, but this bugs means it's not possible to build Docker on anything running a 3.15 kernel, because the build process starts up an Ubuntu container that will try to run things like "chfn" as part of the package install process, which will fail:
|
For the curious, I threw together a quit writeup of the diagnostic process I went through to find the root cause of this behavior: http://blog.oddbit.com/2014/07/21/tracking-down-a-kernel-bug-wit/ |
@larsks thanks for your effort, it made an interesting read! |
I'm sorry to say this, but are you sure that acutally solved the issue? docker --version 1 ↵ docker run -i -t ubuntu:14.04 /bin/bash :( |
@DeX77 Yeah, this is not merged to 1.1.2 |
@LK4D4 thx, then I'll backport that patch for now. |
The docker index is affected by <moby/moby#6345 (comment)>. This fix is an attempt at at temporary workaround and should be reverted once the docker version behind the registry is updated at the next release.
The patch mentioned above to the Dockerfile worked around the issue for me on Fedora 20 w/ kernel 3.15.6-200.fc20.x86_64. |
@slmingol , |
This is occurring to me while Docker Hub builds my Dockerfile... Works fine on boot2docker 1.1.2 |
We are experiencing the same issue... works fine on boot2docker: https://registry.hub.docker.com/u/smartprocure/redis/build_id/11708/code/bkaljywukpqaiigz7n7hlzp/ |
I've tried stracing su in normal and host-network modes, and it looks like NETLINK answer causes su to fail after:
Works(network namespaces):
Host ubuntu 14.04 Docker - latest from git ( image: centos:latest Strace logs https://gist.github.com/iMelnik/0ddf4865dd1c490f2e69 |
We have also experienced the same issue. As visible from strace output, the error is is caused by the audit calls from PAM. Our workaround is to rebuild the libpam on guest OS with --disable-audit flag. The patched CentOS 6.5 and Ubuntu 14.04 unofficial images are available in Docker registry https://registry.hub.docker.com/u/sequenceiq/pam/ and on GitHub https://github.com/sequenceiq/docker-pam . |
Workaround for moby/moby#6345
Creating a new user in a docker container via the
adduser
command will cause an error if the user already exists on the host system and the command is used with the--gecos
flag to supply finger information. This command is commonly run by package managers to create non-privileged users for daemons (e.g. mysql, postgresql).Expected result:
A new user is created in docker container regardless of whether or not it already exists in the host system.
Actual Result:
Creating a new user fails with the error
Steps to Reproduce:
The text was updated successfully, but these errors were encountered: