Bug 861125 - usage of vipw / vigr leads to systemd-logind errors
usage of vipw / vigr leads to systemd-logind errors
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
18
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-27 11:07 EDT by Marcus Moeller
Modified: 2012-10-05 03:46 EDT (History)
3 users (show)

See Also:
Fixed In Version: selinux-policy-3.11.1-28.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-05 03:46:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marcus Moeller 2012-09-27 11:07:15 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.
Comment 1 Tomas Mraz 2012-09-27 12:35:36 EDT
Are you sure the removal of the user caused the error? I'll try to reproduce on a VM clone.
Comment 2 Marcus Moeller 2012-09-27 12:56:21 EDT
Yes, I have re-checked it on another box.
Comment 3 Tomas Mraz 2012-09-27 13:25:22 EDT
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.
Comment 4 Tomas Mraz 2012-09-27 15:49:11 EDT
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
Comment 5 Miroslav Grepl 2012-10-04 05:53:59 EDT
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
Comment 6 Tomas Mraz 2012-10-05 03:46:18 EDT
Yes, I can confirm that the problem is fixed now.

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