[systemd-devel] systemd-nspawn/LXC containers & pam login failure

[Daniel P. Berrange]

On Thu, May 09, 2013 at 03:32:09PM +0200, Lennart Poettering wrote:
> On Thu, 09.05.13 11:38, Daniel P. Berrange (berrange at redhat.com) wrote:
> 
> > Following the suggestion in the systemd-nspawn manpage I populated
> > a mini Fedora 19 chroot, on a Fedora 19 host
> > 
> >   # yum -y --releasever=19 --nogpg --installroot=/srv/mycontainer \
> >         --disablerepo='*' --enablerepo=fedora \
> >         install systemd passwd yum fedora-release vim-minimal
> >   # chroot /srv/mycontainer passwd
> >   # systemd-nspawn -bD /srv/mycontainer
> > 
> > Systemd boots up nicely & presents a login prompt, but it is impossible
> > to actually login, PAM always denying the attempts.
> 
> Yeah, this is a known problem. We generally suggest to turn off audit
> by booting with audit=0 on the kernel cmdline for now:
> 
> https://fedoraproject.org/wiki/Features/SystemdLightweightContainers
> 
> I guess I should add a comment about this to nspawn's man page too.
> 
> The audit folks are working on adding container awareness to the audit
> subsystem in the kernel (which basically means that audit messages carry
> the outside PID of PID1 of the container, so that auditd can track this
> properly). Currently audit is completely confused by PID
> namespacing. Also, we want them to fix for us that opening a PID
> namespace resets loginuid in the container to -1. We have discussed this
> several times with them, and they wanted to something about it, but so
> far nothing happened. But we'll have another meeting about this next
> week, so I can put some pressure on this.

Did you file any BZs against the kernel for this ?  If not I'll sort
out some BZs to track these problems.

> >  2. The audit_log_acct_message() method which is called by pretty
> >     much any PAM module returns EPERM
> > 
> >     There is no actual syscall returning EPERM here. The EPERM
> >     appears to be coming back inside the netlink reply message
> >     from the kernel audit subsystem. Since pretty much every PAM
> >     module sends audit messages, this causes them all to return
> >     fatal errors, failing the login attempt
> > 
> >     The _pam_audit_writelog() method does have code to ignore
> >     EPERM, but it only does so if  'getuid() != 0'. The container
> >     login process has uid == 0, so EPERM is treated as fatal. The
> >     "easy" (but not neccessarily correct) fix is to change
> > 
> >     diff -rup Linux-PAM-1.1.6.orig/libpam/pam_audit.c Linux-PAM-1.1.6.new/libpam/pam_audit.c
> >     --- Linux-PAM-1.1.6.orig/libpam/pam_audit.c     2012-08-15 12:08:43.000000000 +0100
> >     +++ Linux-PAM-1.1.6.new/libpam/pam_audit.c      2013-05-09 10:17:48.679403471 +0100
> >     @@ -46,7 +46,7 @@ _pam_audit_writelog(pam_handle_t *pamh,
> >        pamh->audit_state |= PAMAUDIT_LOGGED;
> > 
> >        if (rc < 0) {
> >     -      if (rc == -EPERM && getuid() != 0)
> >     +      if (rc == -EPERM)
> >                return 0;
> >            if (errno != old_errno) {
> >                old_errno = errno;
> 
> I tried to get a patch like this into PAM actually, but Steve (of
> course) said nononono! He's really married to the idea that audit breaks
> everything on any kind of error... This is kinda sad though, as
> otherwise this would have allowed us to turn off auditing in the
> container completely by removing CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE
> of the container...

I feared that might be the response from PAM maintainers :-(

> I guess libvirt-lxc is in a slightly better situation here regarding
> audit, since it never tries to spawn a container as child of a login
> session, hence loginuid will not be sealed off yet...

If libvirtd has been started from systemd then yes. Of course during
development I just run libvirtd from my source tree directly, so
still hit the problem :-)

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|