Red Hat Bugzilla – Bug 861125
usage of vipw / vigr leads to systemd-logind errors
Last modified: 2012-10-05 03:46:18 EDT
I have removed a user from /etc/passwd using vipw and from /etc/shadow on my Fedora 18 box. After a reboot I can no longer login, due to the following error: systemd-logind : Failed to fully start up daemon: Connection refused You can easily reproduce by adding a user, e.g. using useradd and removing it from passwd afterwards using vipw plus deleting the shadow entry for that user. Afterwards just reboot and you will see the error. I have not yet found a way to get it back up and running yet, so expect a broken system.
Are you sure the removal of the user caused the error? I'll try to reproduce on a VM clone.
Yes, I have re-checked it on another box.
Yes, apparently any editing of /etc/passwd with vipw causes it as the resulting SELinux context on the /etc/passwd will be shadow_t which causes it to become unreadable to multiple confined domains.
This is what happens: 1. vipw sets fscreatecontext to the original context of /etc/passwd (OK) 2. vipw creates /etc/passwd.edit as the copy of /etc/passwd with the same context (OK) 3. vipw executes vi, that runs as sysadm_passwd_t (OK?) 4. vi creates /etc/.passwd.edit.swp but the context is shadow_t and uses it to save the edited passwd (why the context of the file is shadow_t?) 5. vi renames the .swp file over the /etc/passwd.edit - now it has wrong shadow_t 6. vi tries to relabel it to the original passwd_file_t and it is denied to do it by selinux 7. vipw renames the /etc/passwd.edit to /etc/passwd -> boom
Tomas, I am not able to reproduce it with the latest F18 policy. # rpm -q selinux-policy selinux-policy-3.11.1-28.fc18.noarch /etc/passwd remains labeled as passwd_file_t Steps: # vipw -p # ls -Z /etc/.passwd* -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd- -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd.edit -rw-------. root root system_u:object_r:passwd_file_t:s0 /etc/passwd.lock -rw-r--r--. root root system_u:object_r:etc_t:s0 /etc/passwdqc.conf # edit passwd # tail /etc/passwd -n 1 test:: # ls -Z /etc/passwd -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd # getenforce Enforcing
Yes, I can confirm that the problem is fixed now.