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:
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>
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>
Signed-off-by: Eric Paris <eparis(a)redhat.com>
: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
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit