When I create a container using the instructions listed on the systemd lightweight container feature page [1], I am unable to login to the booted system after setting the root password. [1] http://fedoraproject.org/wiki/Features/SystemdLightweightContainers The exact process I followed is as follows: Create the container: yum -y --releasever=19 --nogpg --installroot=/srv/container1 --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal Set the root password: # systemd-nspawn -D /srv/container1 # passwd Boot the container: systemd-nspawn -bD /srv/mycontainer 3 At this point, I get a login prompt. If I attempt to login as root using the password I set, I always get dumped back to the login prompt after the follwoing error: Cannot make/remove an entry for the specified session If I get back into the system using systemd-nspawn -D, I can get some logs using journalctl. The error messages that seem to be at fault are: May 23 20:08:46 container1 login[20]: pam_loginuid(login:session): set_loginuid failed May 23 20:08:46 container1 systemd-logind[18]: New session 1 of user root. May 23 20:08:46 container1 login[20]: pam_unix(login:session): session opened for user root by (uid=0) May 23 20:08:46 container1 login[20]: Cannot make/remove an entry for the specified session Other potentially relevant information: systemd-204-3.fc19 host is a bare metal F19 beta install # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.9.3-301.fc19.x86_64 root=UUID=c4f4623e-3edc-4660-a517-e4722e215787 ro nomodeset rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=us rd.luks=0 vconsole.font=latarcyrheb-sun16 rhgb quiet audit=0 selinux=0
As another data point, I tried the same set of commands in an updated F18 VM (booted with audit=0 and selinux=0) and was able to login to the F19 container.
audit=0 is the problem (not selinux=0) We are working to resolv this issue upstream. Kernel patches start here: https://www.redhat.com/archives/linux-audit/2013-May/msg00065.html Once they are settled systemd would need to do some patches to enable this feature. If you want the container to work with audit=1 you will have to launch it from a systemd unit file instead of by running nsspawn by hand.
(In reply to Eric Paris from comment #2) > audit=0 is the problem (not selinux=0) Yeah, I just tried selinux=0 after reading that selinux can get confused with selinux containers. I did boot with audit=0 from the start > We are working to resolv this issue upstream. Kernel patches start here: > > https://www.redhat.com/archives/linux-audit/2013-May/msg00065.html > > Once they are settled systemd would need to do some patches to enable this > feature. > > If you want the container to work with audit=1 you will have to launch it > from a systemd unit file instead of by running nsspawn by hand. Are those patches to enable systemd containers with audit=1 or to fix this problem which is logging into the container with audit=0?
Until this is fixed, a workaround is to comment out the pam_loginuid line in /etc/pam.d/login.
*** Bug 970976 has been marked as a duplicate of this bug. ***
*** Bug 1038115 has been marked as a duplicate of this bug. ***
(In reply to Jeff Peeler from comment #4) > Until this is fixed, a workaround is to comment out the pam_loginuid line in > /etc/pam.d/login. If I'm reading correctly, you're saying, if you comment out the 'pam_loginuid.so' line in /etc/pam.d/login _despite_ audit=1, it should work. This workaround doesn't work for me. (However, I have a Fedora-20 system w/ audit=0 where I do my test builds, etc. I just tried this out of curiosity.) Boot into the container: $ systemd-nspawn -bD /srv/testcontainer -bash-4.2# Comment out pam_loginuid.so: -bash-4.2# cat /etc/pam.d/login | grep pam_loginuid.so #session optional pam_loginuid.so Add a user and try to create password for it (or try to boot: -bash-4.2# useradd tuser1 -bash-4.2# passwd tuser1 Changing password for user tuser1. New password: BAD PASSWORD: The password is shorter than 8 characters Retype new password: passwd: System error Query the systemd journal of the container: $ journalctl -D /srv/testcontainer/var/log/journal | grep PAM -A2 -B1 [. . .] Jan 30 12:17:16 testcontainer login[24]: pam_unix(login:auth): authentication failure; logname= uid=0 euid=0 tty=console ruser= rhost= user=root Jan 30 12:17:18 testcontainer login[24]: PAM audit_log_acct_message() failed: Operation not permitted Jan 30 12:17:18 testcontainer login[24]: FAILED LOGIN SESSION FROM console FOR root, System error Jan 30 12:17:23 testcontainer systemd[1]: console-getty.service holdoff time over, scheduling restart.
Shame on me for not being a little more detailed about what I was talking about. Don't remember at this point, but I'm pretty sure I had zero success with audit=1.
(In reply to Kashyap Chamarthy from comment #7) > (In reply to Jeff Peeler from comment #4) > > Until this is fixed, a workaround is to comment out the pam_loginuid line in > > /etc/pam.d/login. > > If I'm reading correctly, you're saying, if you comment out the > 'pam_loginuid.so' line in /etc/pam.d/login _despite_ audit=1, it should work. > > > This workaround doesn't work for me. (However, I have a Fedora-20 system w/ > audit=0 where I do my test builds, etc. I just tried this out of curiosity.) > > Boot into the container: > > $ systemd-nspawn -bD /srv/testcontainer Small typo: that's was supposed to be -- $systemd-nspawn -D /srv/testcontainer. (-b will boot it with systemd in a namespace container) > -bash-4.2# > > Comment out pam_loginuid.so: > > -bash-4.2# cat /etc/pam.d/login | grep pam_loginuid.so > #session optional pam_loginuid.so > > Add a user and try to create password for it (or try to boot: > -bash-4.2# useradd tuser1 > -bash-4.2# passwd tuser1 > Changing password for user tuser1. > New password: > BAD PASSWORD: The password is shorter than 8 characters > Retype new password: > passwd: System error > > > Query the systemd journal of the container: > > $ journalctl -D /srv/testcontainer/var/log/journal | grep PAM -A2 -B1 > [. . .] > Jan 30 12:17:16 testcontainer login[24]: pam_unix(login:auth): > authentication failure; logname= uid=0 euid=0 tty=console ruser= rhost= > user=root > Jan 30 12:17:18 testcontainer login[24]: PAM audit_log_acct_message() > failed: Operation not permitted > Jan 30 12:17:18 testcontainer login[24]: FAILED LOGIN SESSION FROM console > FOR root, System error > Jan 30 12:17:23 testcontainer systemd[1]: console-getty.service holdoff > time over, scheduling restart.
In kernel v3.14-rc1 nsspawn/whatever clones the namespaces should be able to set the loginuid to 4294967295 before launching anything inside and it should be resolved...
systemd-nspawn makes use of this in http://cgit.freedesktop.org/systemd/systemd/commit/?id=db999e0. In addition http://cgit.freedesktop.org/systemd/systemd/commit/?id=24fb111 is necessary to get a working login with default PAM configuration and audit=1.
------- Comment From cdeadmin.com 2014-02-17 06:14 EDT-------
This should work with systemd 209.
I can confirm, this works with: $ uname -r; rpm -q systemd 3.14.0-0.rc4.git0.1.fc21.x86_64 systemd-210-2.fc21.x86_64 $ auditctl -s AUDIT_STATUS: enabled=1 flag=1 pid=816 rate_limit=0 backlog_limit=320 lost=0 backlog=0 $ systemd-nspawn -bD testcontainer [. . .] $ machinectl status testcontainer testcontainer Since: Thu 2014-02-27 11:00:47 EST; 2min 32s ago Leader: 1626 (systemd) Service: nspawn; class container Root: /srv/testcontainer Unit: machine-testcontainer.scope ├─1626 /usr/lib/systemd/systemd └─system.slice ├─console-getty.service │ ├─1697 login -- root │ └─1884 -bash ├─crond.service │ ├─1695 /usr/sbin/crond -n │ └─1847 /usr/sbin/anacron -s ├─libvirtd.service │ └─1687 /usr/sbin/libvirtd ├─dbus.service │ └─1686 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation ├─rpcbind.service │ └─1692 /sbin/rpcbind -w ├─lvm2-lvmetad.service │ └─1665 /usr/sbin/lvmetad └─systemd-journald.service └─1650 /usr/lib/systemd/systemd-journald
This is unlikely to get fixed in F19 or F20, but F21 should be OK.
Could someone please provide a workaround for this on F20? What would I need to do to be able to login to an LXC instance on F20? Or are there any description on how to deal with this somewhere else? Thanks
boot with audit=0 in the kernel command line.