Ugh!  I proofread that message, really, but I overlooked the subject line which I meant to rephrase.  There is no CONFIG_AUDIT option in x86-64 that I'm aware of, but the message I sent is a bug that seems to bisect down to a change related to linux-audit. Sorry for the misleading subject line. Adam Richter On Friday, February 14, 2014 2:56 PM, Adam Richter <adam_richter2004(a)yahoo.com&gt; wrote: Hi. If I take an Ubuntu 13.10-amd64 system and install an Ubuntu 13.04-i386 Linux Container, it works fine with kernel.org kernel releases through Linux-3.13, but, for Linux-13.14-rc1 and beyond, I cannot login with "lxc-console".  In that case, if I try to log in as "ubuntu" with the correct password, it quickly tell me the login was incorrect, and prompts me with a new "login:" prompt, but without the delay that occurs if I type in the wrong password.  I haven't bothered breaking into the "linux container", but, looking at its log files from the outside as it runs, I see some PAM errors about "operation not permitted." I have reproduced this problem with the following container configurations, all on an Ubuntu 13.10-amd64 hosts ("amd64" is Ubuntu's terminology, not my jibing Intel): Ubuntu 13.04-i386 Ubuntu 13.10-i386 Ubuntu 13.10-amd64 I have also reproduced this with a kernel built from git://git.infradead.org/users/eparis/audit.git yesterday (Ubuntu 13.10-amd64 hosting an Ubuntu 13.04-i386 container). I have also tried disabling CONFIG_AUDIT{SYSCALL,_WATCH,_TREE} and CONFIG_KVM_MMU_AUDIT from linux-3.14-rc2-x86_64 and still observed the same problem. Doing a "git bisect" on Linus's public tree brought me to the following change (Ubuntu 13.10-x86_64 hosting an Ubuntu 13.04-i386 container): 33faba7fa7f2288d2f8aaea95958b2c97bf9ebfb is the first bad commit commit 33faba7fa7f2288d2f8aaea95958b2c97bf9ebfb Author: Richard Guy Briggs <rgb(a)redhat.com&gt; Date:   Tue Jul 16 13:18:45 2013 -0400     audit: listen in all network namespaces         Convert audit from only listening in init_net to use register_pernet_subsys()     to dynamically manage the netlink socket list.         Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com&gt;     Signed-off-by: Eric Paris <eparis(a)redhat.com&gt; :040000 040000 3c5f63118d5fe9b5a4f0a6dd828249979a10ffa0 c8feaa4fd9bc260cde3bb703ff20ae6938fabe6a M    kernel For those of you who are not used to using Linux Containers, here are some commands that should reproduce the bug, although I am going from memory rather than copying from my command history. % sudo lxc-create -t ubuntu -n myubuntu13.04 -- --release raring --arch i386 # ^^ This takes a while.  It installs a Linux distribution in a directory. % sudo lxc-start -n myubuntu13.04 -d % sudo lxc-console -n myubuntu13.04 ...Try to log in as "ubuntu" with password "ubuntu".  When you'd done, do <ctrl-A>q to disconnect the session. % sudo lxc-stop -n myubuntu13.04 # This next command basically does "rm -rf" on the container's directory tree. % sudo lxc-destroy -n myubuntu13.04 In the above example, change "raring" to "saucy" if you want Ubuntu 13.10.  You can change i386 to amd64 to try 64-bit.  "myubuntu13.04" is just a name, which you can change to whatever you want.  The Fedora container template shipped with Ubuntu 13.10 does not install for me, otherwise I would have tested that too. I am not yet sure if this is really a kernel bug or if this is a case of a valid change in Linux kernel behavior exposing a bug elsewhere (for example, Ubuntu's PAM configuration).  I am not a Linux Audit developer.  I am hoping that, if this is a Linux Audit bug, you folks will be able to take it from here, but I'm happy to try to help as best I can. Thanks in advance for any help with this. Adam

Hi, Eric. Thank you for your detailed reply.  I confirm that adding "audit=0" to the boot arguments to my linux-3.14-rc2-x86_64 kernel running Ubuntu 13.10-x86_64 allowed me to log into an Ubuntu 13.04-i386 container.  Thank you for providing this work around, and please feel free to let me know if there is anything else you'd like me to try. Adam Richter On Monday, February 17, 2014 11:02 AM, Eric Paris <eparis(a)redhat.com&gt; wrote: boot with audit=0 on the command line and it will work. The basic problem is that before this patch, trying to connect to the kernel audit infrastructure when setting up a separate network namespace returned EOPNOTSUPP or some such thing which told the pam stack that audit was not compiled into the kernel. This patch means that the kernel audit is actually listening in the network namespace.  But, mostly likely, it is now rejecting the pam module request because the new container is in a new pid namespace.  We should have patches to allow that in the next kernel release. Let me know if booting with audit=0 gets you login in a container back... On Fri, 2014-02-14 at 14:56 -0800, Adam Richter wrote: