Description of problem: Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Create an image virt-builder fedora-20 \ --size 30G \ --format qcow2 \ -o $UNDERCLOUD_VM_NAME.qcow2 \ --root-password password:redhat \ --update 2. Import the image into virt-manager and run it Actual results: Attempt to login. After entering the proper username and password, login prompt is displayed again. Expected results: Successful login. Additional info:
I'm guessing this is an SELinux / labelling problem. Does the label look right on the password file? Try: guestfish --ro -a vm-name.qcow2 -i llz /etc Do the SELinux labels on /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow look reasonable? (ie. the same as a similar Fedora 20). Does the content of /etc/passwd and /etc/shadow look reasonable? Try: virt-cat -a vm-name.qcow2 /etc/passwd virt-cat -a vm-name.qcow2 /etc/shadow Did the guest reboot on its own the first time it was booted? This should happen to do the SELinux relabelling. Also I will need to know which version of virt-builder this is. FWIW I tried the same command as above and this works for me with and without --update, using virt-builder 1.26 on a Fedora 20 host.
Also please try the latest version in Fedora 20 updates-testing: https://admin.fedoraproject.org/updates/FEDORA-2014-4532/supermin-5.1.6-5.fc20,libguestfs-1.26.0-1.fc20
I can also reproduce this. It is happening with virt-builder 1.28.6-1 on Fedora 21 host. I am running it as: virt-builder fedora-21 -o fedora21.img --update --root-password password:weakpassword and when I put that image into virtmanager, I am unable to log in as a root. I got the same result when I changed "--update" to "--run-command 'yum -y update'". But when I created that image without "--update", login worked, even after I ran "yum -y update" after first login and rebooted. Here is output from "guestfish --ro -a vm-name.qcow2 -i llz /etc" on image created with --update: ----------. root root system_u:object_r:shadow_t:s0 shadow ----------. root root system_u:object_r:shadow_t:s0 shadow- -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 passwd -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 passwd- -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 group -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 group- ----------. root root system_u:object_r:shadow_t:s0 gshadow ----------. root root system_u:object_r:shadow_t:s0 gshadow- Image that was updated by hand has the same labeling. Both images have the same /etc/passwd. They have different password hashes in /etc/shadow: [garret@dhcp-29-204 tools]$ virt-cat -a fedora21.img /etc/shadow > a [garret@dhcp-29-204 tools]$ virt-cat -a fedora21b.img /etc/shadow > b [garret@dhcp-29-204 tools]$ diff a b 1c1 < root:$6$hhFRk60vqAtKKWpv$6J8umNEee4.v/E0/rPh2SbdEg6VQPAxH6uU8O.Is1IG/HQTwoMXc9LfsUZBspV3PaqjRqW/2SJsxdMBJLQF8z0::0:99999:7::: --- > root:$6$CW5JHEqAb6t71zv4$3DuG2VufvLiVvN9bg.LIjwZcN0COsNuf/DCNvcTI9jEJNCPRsWkQ0jHE.4lLgSL53odx0tHvz0qnzjhRFSn2h0::0:99999:7::: Also, machine didn't rebooted the first time it was booted. I have rebooted it and it still doesn't work.
It doesn't seem to be SELinux in that case. Can you pull out the log files and see if there is any clue as to why the login was not permitted? $ virt-tar-out -a image_where_login_failed.img /var/log - | tar -C /tmp -xv Then have a look in /tmp/messages /tmp/secure/* etc. and see if you can find an error message.
I'm able to reproduce this now. There are no interesting audit messages in audit/audit.log, so it's probably not due to SELinux. Accessing the journal: $ journalctl -D ./journal shows that the login was successful, but then immediately failed, although the reason is not clear: Mar 11 13:18:37 localhost.localdomain login[774]: pam_unix(login:session): sessi on opened for user root by LOGIN(uid=0) Mar 11 13:18:37 localhost.localdomain login[774]: ROOT LOGIN ON tty1 Mar 11 13:18:37 localhost.localdomain systemd[1]: Started User Manager for UID 0 . Mar 11 13:18:37 localhost.localdomain login[774]: pam_unix(login:session): sessi on closed for user root Mar 11 13:18:37 localhost.localdomain systemd[1]: getty has no hold off time, scheduling restart. Mar 11 13:18:37 localhost.localdomain systemd-logind[324]: Removed session 2. Mar 11 13:18:37 localhost.localdomain systemd[1]: Stopping User Manager for UID 0... I'm going to install rsyslog so I get proper log files.
When I put "selinux=0" on kernel line in Grub, I am able to log in and /var/log/audit contains audit.log. I am attaching output from "sealert -a audit.log".
Created attachment 1000438 [details] output from sealert -a audit.log
Oh I see, it *is* SELinux: type=AVC msg=audit(1426080555.703:344): avc: denied { transition } for pid=773 comm="login" path="/usr/bin/bash" dev="vda3" ino=131727 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=0 type=AVC msg=audit(1426080559.624:364): avc: denied { transition } for pid=792 comm="login" path="/usr/bin/bash" dev="vda3" ino=131727 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=0 audit2allow suggests: #============= kernel_t ============== allow kernel_t unconfined_t:process transition;
(In reply to Jan Sedlák from comment #7) > Created attachment 1000438 [details] > output from sealert -a audit.log I can confirm your results match mine, so reassigning to selinux-policy.
Actually I'm not convinced that SELinux is to blame for this. I think the problem is that /usr/bin/bash didn't get labelled by virt-builder. Still investigating ...
OK I believe this is another example of bug 1089100, and is a bug in virt-builder, not SELinux. If you add the `virt-builder --selinux-relabel' flag then it works. That flag shouldn't be necessary long-term, but it does no harm to add it for guests that require SELinux. The only side effect is the guest may take slightly longer to boot (about 20 seconds longer in my test). *** This bug has been marked as a duplicate of bug 1089100 ***