Bug 966807
Summary: | Can't login to systemd lightweight container | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tim Flink <tflink> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | andmalc, asaha, atorkhov, bugproxy, eparis, henrikk52, johannbg, jpeeler, kchamart, lnykryn, msekleta, notting, plautrba, systemd-maint, tuksgig, vpavlin, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-03-12 02:34:10 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1000189 |
Description
Tim Flink
2013-05-24 02:57:06 UTC
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. |