Bug 966807 - Can't login to systemd lightweight container
Summary: Can't login to systemd lightweight container
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 970976 1038115 (view as bug list)
Depends On:
Blocks: systemd-containers
TreeView+ depends on / blocked
 
Reported: 2013-05-24 02:57 UTC by Tim Flink
Modified: 2014-04-22 18:27 UTC (History)
17 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-03-12 02:34:10 UTC


Attachments (Terms of Use)

Description Tim Flink 2013-05-24 02:57:06 UTC
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

Comment 1 Tim Flink 2013-05-24 22:18:58 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.

Comment 2 Eric Paris 2013-05-28 17:10:02 UTC
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.

Comment 3 Tim Flink 2013-05-29 03:53:06 UTC
(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?

Comment 4 Jeff Peeler 2013-05-31 22:11:26 UTC
Until this is fixed, a workaround is to comment out the pam_loginuid line in /etc/pam.d/login.

Comment 5 Lennart Poettering 2013-06-07 06:55:48 UTC
*** Bug 970976 has been marked as a duplicate of this bug. ***

Comment 6 Alexey Torkhov 2013-12-04 20:42:01 UTC
*** Bug 1038115 has been marked as a duplicate of this bug. ***

Comment 7 Kashyap Chamarthy 2014-01-30 06:57:20 UTC
(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.

Comment 8 Jeff Peeler 2014-01-30 17:01:57 UTC
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.

Comment 9 Kashyap Chamarthy 2014-01-30 18:16:42 UTC
(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.

Comment 10 Eric Paris 2014-01-31 19:47:45 UTC
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...

Comment 11 Zbigniew Jędrzejewski-Szmek 2014-02-17 06:10:11 UTC
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 12 IBM Bug Proxy 2014-02-17 13:20:16 UTC
------- Comment From cdeadmin@us.ibm.com 2014-02-17 06:14 EDT-------

Comment 13 Lennart Poettering 2014-02-23 16:48:37 UTC
This should work with systemd 209.

Comment 14 Kashyap Chamarthy 2014-02-27 10:33:43 UTC
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

Comment 15 Zbigniew Jędrzejewski-Szmek 2014-03-12 02:34:10 UTC
This is unlikely to get fixed in F19 or F20, but F21 should be OK.

Comment 16 HenrikK 2014-04-22 18:25:36 UTC
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

Comment 17 Eric Paris 2014-04-22 18:27:04 UTC
boot with audit=0 in the kernel command line.


Note You need to log in before you can comment on or make changes to this bug.