Bug 679842 - Systemd udev rule prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition
Systemd udev rule prevents systemd-tty-ask from collecting password for unloc...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
AcceptedBlocker RejectedNTH
: Reopened, SELinux
Depends On: 678927
Blocks: F15Beta/F15BetaBlocker
  Show dependency treegraph
 
Reported: 2011-02-23 12:06 EST by Miroslav Grepl
Modified: 2011-07-25 08:06 EDT (History)
13 users (show)

See Also:
Fixed In Version: systemd-20-1.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 678927
Environment:
Last Closed: 2011-03-11 23:42:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Miroslav Grepl 2011-02-23 12:06:01 EST
+++ This bug was initially created as a clone of Bug #678927 +++

Created attachment 479795 [details]
output of dmesg command

Description of problem:
When booting my system I get SELinux denial on systemd-tty-ask and then system freezes for half a minute or so and then it continues in startup, but it is not unlocking encrypted partitions (/home and swap), so the system start without /home and swap. The latter is not important for me (I have 4GB physical RAM on my computer), but the former completely breaks my login to Gnome. I have to switch back to console, unlock partitions, switch between runlevel 3 and back to runlevel 5 to get real gdm login.

Just to be sure, system is just after
touch /.autorelabel ; reboot
operation, so bad labels shouldn't be the issue.

And yes, this happens even though I have SELinux in a permissive mode.

Version-Release number of selected component (if applicable):
selinux-policy-3.9.15-1.fc16.noarch
systemd-18-1.fc16.x86_64


How reproducible:
100%

Additional info:
jakoubek:~# dmesg |grep avc
[   13.736246] type=1400 audit(1298238053.417:3): avc:  denied  { mmap_zero } for  pid=532 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
[   17.917743] type=1400 audit(1298238057.598:4): avc:  denied  { write } for  pid=839 comm="systemd-tty-ask" name="sck.14102234336533528066" dev=devtmpfs ino=11937 scontext=system_u:system_r:systemd_passwd_agent_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=sock_file
[   74.781576] dbus[900]: avc:  netlink poll: error 4
[   75.016982] type=1400 audit(1298238114.697:5): avc:  denied  { sys_tty_config } for  pid=950 comm="cgconfigparser" capability=26  scontext=system_u:system_r:cgconfig_t:s0 tcontext=system_u:system_r:cgconfig_t:s0 tclass=capability

--- Additional comment from lpoetter@redhat.com on 2011-02-21 09:51:51 EST ---

Dan?

--- Additional comment from dwalsh@redhat.com on 2011-02-21 11:18:42 EST ---

First remove the vbetool which you probably do not need, this will remove the mmap_zero avc.

Second we can add the sys_tty_config for cgconfig_t.

THe systemd-tty-ask writing to a sock_file labled device_t looks like a bug in the app that created the socket.  Lennart, do you know which executable would have created this sock_file? sck.14102234336533528066?  Under /dev

If this happens in permissive mode, it is most likely not related to SELinux.

--- Additional comment from lpoetter@redhat.com on 2011-02-21 16:43:57 EST ---

(In reply to comment #2)

> THe systemd-tty-ask writing to a sock_file labled device_t looks like a bug in
> the app that created the socket.  Lennart, do you know which executable would
> have created this sock_file? sck.14102234336533528066?  Under /dev

That's systemd-cryptsetup tool which places a text file containing a question and a socket to receive the response on in /dev/.systemd/ask-password. Some kind of agent (during boot that is plymouth) then sees that (via inotify) and brings it on the screen, passing the entered password back to systemd-cryptsetup via the socket.

--- Additional comment from jlaska@redhat.com on 2011-02-22 14:00:29 EST ---

I believe this use case is captured by the following F-15-Alpha release criteria [1].

    "The installer must be able to complete an installation using the 
     entire disk, existing free space, or existing Linux partitions 
     methods, with or without encryption enabled "

Given a large enough disk, anaconda recommends a separate /home partition.  Considering that with a big enough disk, this is the default scenario and doesn't require custom partitioning, I believe this issue is captured by the above criteria.  I support this as an Alpha release blocker.

[1] https://fedoraproject.org/wiki/Fedora_15_Alpha_Release_Criteria

--- Additional comment from mgrepl@redhat.com on 2011-02-23 11:32:28 EST ---

But still, this happens in permissive mode as Matej wrote above.

--- Additional comment from mgrepl@redhat.com on 2011-02-23 12:04:44 EST ---

Matej,
btw. how is labeled your systemd-cryptsetup

# ls -Z /lib/systemd/systemd-cryptsetup

Do you have disabled unconfined module also? If yes, I think you should see different AVC msgs which I am seeing.
Comment 1 Lennart Poettering 2011-02-23 12:16:04 EST
Hmm, why did this get duplicated against systemd? This needs a policy change, no change in systemd. Or am I missing something?
Comment 2 Miroslav Grepl 2011-02-23 12:26:25 EST
The problem is it does not work in permissive mode as Matej wrote.

> And yes, this happens even though I have SELinux in a permissive mode.
Comment 3 Lennart Poettering 2011-02-23 15:06:36 EST
Uh, if the boot stays stuck my guess this is due to LVM borkage and has nothing to do with selinux.

https://bugzilla.redhat.com/show_bug.cgi?id=679321

Matej, are you using LVM? Does "udevadm -qall -p /sys/class/block/dm..." show those flags mentioned in the bug report?
Comment 4 Matěj Cepl 2011-02-24 18:21:55 EST
jakoubek:mapper# /bin/ls -l
celkem 0
crw-------. 1 root root 10, 236 24. úno 09.01 control
lrwxrwxrwx. 1 root root       7 24. úno 16.19 home -> ../dm-8
lrwxrwxrwx. 1 root root       7 24. úno 09.01 vg_bradford-lv_home -> ../dm-0
lrwxrwxrwx. 1 root root       7 24. úno 09.01 vg_bradford-lv_swap -> ../dm-2
jakoubek:mapper# udevadm -p /sys/class/block/dm-8 -q all
udevadm: invalid option -- 'p'
jakoubek:mapper# udevadm info -p /sys/class/block/dm-8 -q all
P: /devices/virtual/block/dm-8
N: dm-8
S: mapper/home
S: disk/by-id/dm-name-home
S: disk/by-id/dm-uuid-CRYPT-LUKS1-4fc6bff38bc541b897b382631d58665a-home
S: disk/by-uuid/ace27985-bead-409c-9165-86881ba7a101
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/block/dm-8
E: MAJOR=253
E: MINOR=8
E: DEVNAME=/dev/dm-8
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: DM_SBIN_PATH=/sbin
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES_VSN=2
E: DM_NAME=home
E: DM_UUID=CRYPT-LUKS1-4fc6bff38bc541b897b382631d58665a-home
E: DM_SUSPENDED=0
E: ID_FS_UUID=ace27985-bead-409c-9165-86881ba7a101
E: ID_FS_UUID_ENC=ace27985-bead-409c-9165-86881ba7a101
E: ID_FS_VERSION=1.0
E: ID_FS_TYPE=ext4
E: ID_FS_USAGE=filesystem
E: FSTAB_NAME=/dev/mapper/home
E: FSTAB_DIR=/home
E: FSTAB_TYPE=ext4
E: FSTAB_OPTS=defaults
E: FSTAB_FREQ=1
E: FSTAB_PASSNO=2
E: UDISKS_PRESENTATION_NOPOLICY=1
E: UDISKS_DM_TARGETS_COUNT=1
E: UDISKS_DM_TARGETS_TYPE=crypt
E: UDISKS_DM_TARGETS_START=0
E: UDISKS_DM_TARGETS_LENGTH=204795960
E: DEVLINKS=/dev/mapper/home /dev/disk/by-id/dm-name-home /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-4fc6bff38bc541b897b382631d58665a-home /dev/disk/by-uuid/ace27985-bead-409c-9165-86881ba7a101
E: TAGS=:systemd:

jakoubek:mapper# udevadm info -p /sys/class/block/dm-0 -q all
P: /devices/virtual/block/dm-0
N: dm-0
S: mapper/vg_bradford-lv_home
S: vg_bradford/lv_home
S: disk/by-id/dm-name-vg_bradford-lv_home
S: disk/by-id/dm-uuid-LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkVVqafrkB2QU9fbcc1qIaORtn82kGJcJ9L
S: disk/by-uuid/4fc6bff3-8bc5-41b8-97b3-82631d58665a
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/block/dm-0
E: MAJOR=253
E: MINOR=0
E: DEVNAME=/dev/dm-0
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: DM_SBIN_PATH=/sbin
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES_VSN=2
E: DM_NAME=vg_bradford-lv_home
E: DM_UUID=LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkVVqafrkB2QU9fbcc1qIaORtn82kGJcJ9L
E: DM_SUSPENDED=0
E: DM_VG_NAME=vg_bradford
E: DM_LV_NAME=lv_home
E: DEVLINKS=/dev/mapper/vg_bradford-lv_home /dev/vg_bradford/lv_home /dev/disk/by-id/dm-name-vg_bradford-lv_home /dev/disk/by-id/dm-uuid-LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkVVqafrkB2QU9fbcc1qIaORtn82kGJcJ9L /dev/disk/by-uuid/4fc6bff3-8bc5-41b8-97b3-82631d58665a
E: ID_FS_UUID=4fc6bff3-8bc5-41b8-97b3-82631d58665a
E: ID_FS_UUID_ENC=4fc6bff3-8bc5-41b8-97b3-82631d58665a
E: ID_FS_VERSION=1
E: ID_FS_TYPE=crypto_LUKS
E: ID_FS_USAGE=crypto
E: UDISKS_PRESENTATION_NOPOLICY=1
E: TAGS=:systemd:

jakoubek:mapper# udevadm info -p /sys/class/block/dm-2 -q all
P: /devices/virtual/block/dm-2
N: dm-2
S: mapper/vg_bradford-lv_swap
S: vg_bradford/lv_swap
S: disk/by-id/dm-name-vg_bradford-lv_swap
S: disk/by-id/dm-uuid-LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkV23nCXk2egJm8ul7Z2xC9xIsdB9x0DG89
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/block/dm-2
E: MAJOR=253
E: MINOR=2
E: DEVNAME=/dev/dm-2
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: DM_SBIN_PATH=/sbin
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES_VSN=2
E: DM_NAME=vg_bradford-lv_swap
E: DM_UUID=LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkV23nCXk2egJm8ul7Z2xC9xIsdB9x0DG89
E: DM_SUSPENDED=0
E: DM_VG_NAME=vg_bradford
E: DM_LV_NAME=lv_swap
E: DEVLINKS=/dev/mapper/vg_bradford-lv_swap /dev/vg_bradford/lv_swap /dev/disk/by-id/dm-name-vg_bradford-lv_swap /dev/disk/by-id/dm-uuid-LVM-G4JpX1Dmn3wPnJECdWOmEKH2RqoPzNkV23nCXk2egJm8ul7Z2xC9xIsdB9x0DG89
E: UDISKS_PRESENTATION_NOPOLICY=1
E: SYSTEMD_READY=0
E: TAGS=:systemd:
Comment 5 Lennart Poettering 2011-02-24 19:54:36 EST
Matej, yupp, this is the LVm problem:

E: UDISKS_PRESENTATION_NOPOLICY=1
E: SYSTEMD_READY=0.
Comment 6 Lennart Poettering 2011-02-24 19:55:02 EST

*** This bug has been marked as a duplicate of bug 679321 ***
Comment 7 Matěj Cepl 2011-02-25 04:42:41 EST
(In reply to comment #5)
> Matej, yupp, this is the LVm problem:
> 
> E: UDISKS_PRESENTATION_NOPOLICY=1
> E: SYSTEMD_READY=0.

After discussing it with LVM folks, it seems that more like udev problem which hits LVM first, but whatever. I agree, it is duplicate of the bug you closed it against.
Comment 8 Milan Broz 2011-02-25 07:10:37 EST
This is somehing different.
UDISKS_PRESENTATION_NOPOLICY is apparently correct, see udisks rule:

ENV{UDISKS_PRESENTATION_NOPOLICY}="1"
KERNEL=="sd*|hd*|sr*|mmcblk*|mspblk*", ENV{UDISKS_PRESENTATION_NOPOLICY}="0"

Now, why is SYSTEM_READY=0 ? only for swap LV!

but in udev db is NOT DM_UDEV_DISABLE_OTHER_RULES_FLAG set... strange

SUBSYSTEM=="block", KERNEL!="ram*|loop*", ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", ENV{SYSTEMD_READY}="0"
Comment 9 Milan Broz 2011-02-25 07:28:16 EST
This systemd udev rule is wrong:

SUBSYSTEM=="block", KERNEL!="ram*|loop*", ENV{ID_PART_TABLE_TYPE}=="", ENV{ID_FS_USAGE}=="", ENV{SYSTEMD_READY}="0"

if ID_PART_TABLE_TYPE and D_FS_USAGE is empty, it sets SYSTEMD_READY=0.

And it is for swap LV (no LUKS header).
Comment 10 Bruno Wolff III 2011-02-25 12:47:37 EST
From alpha blocker meeting:
#agreed no data changes the impact of 679842, it remains not an alpha blocker. agreed by all that it is a beta blocker. voted not alpha NTH by 5 to 2.
Comment 11 Lennart Poettering 2011-02-28 16:05:49 EST
Fixed in systemd git, upload will follow shortly.
Comment 12 Milan Broz 2011-02-28 17:39:24 EST
If the fix is
http://cgit.freedesktop.org/systemd/commit/?id=90e6abaea0cfd25093aae1ad862c5c909ae55829

I must admit that I do not understand this patch. I thought the fix should be opposite (ENV{DM_UUID}!="CRYPT-*") - why systemd is marking crypt device SYSTEMD_READY=0?
Comment 13 Lennart Poettering 2011-02-28 19:52:35 EST
In /etc/crypttab you can mark a device with the "tmp" or "swap" options. If that is done the crypto device is set up (usually with a key from /dev/urandom) and then mke2fs resp. mkswap is called on it. Now, systemd will notice the device as soon as it is set up via cryptsetup, and before this udev rule existed it would then immediately go and invoke depending units right-away (without waiting for mke2fs/mkswap), which would then very likely call swapon or mount. However, since that would run in parallel with the mke2fs/mkswap this would of course fail. To protect us from that we then added the original rule and set SYSTEMD_READY=0 as long as no superblock could be found on a block device, under the assumption that nothing is lost this way, because what can you do with a block device with no superblock of any kind that would be relevant to systemd dependencies? Well, turns out that it actually can contain a raw encrypted device which is not detected as superblock.

This change now limits the additional check the effect of the superblock checking: we will do so only if this is actually on an encrypted device, because only then we might end up call mke2fs/mkswap on it which we need to wait for. This should fix the problem, except of course of folks who stack encrypted device on top of each other...
Comment 14 Fedora Update System 2011-02-28 20:37:38 EST
Package systemd-19-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-19-1.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/systemd-19-1.fc15
then log in and leave karma (feedback).
Comment 15 Fedora Update System 2011-03-01 01:49:14 EST
systemd-19-1.fc15 has been pushed to the Fedora 15 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update systemd'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-19-1.fc15
Comment 16 Matěj Cepl 2011-03-01 07:49:29 EST
Yes, this really have been fixed. Thank you
Comment 17 Fedora Update System 2011-03-08 14:36:58 EST
systemd-20-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/systemd-20-1.fc15
Comment 18 Fedora Update System 2011-03-11 23:42:35 EST
systemd-20-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 Sami Farin 2011-07-25 08:06:06 EDT
systemd 30 does not enable encryption for swap.
28 or something did, 29 did not manage to boot my system.

This setup worked OK for nine years,... and then systemd came :(

# grep swap /etc/fstab
LABEL=wd1swap   swap                    swap    pri=10,encryption=AES128,loop=/dev/loop6
LABEL=wd2swap   swap                    swap    pri=10,encryption=AES128,loop=/dev/loop4

# swapon -s
Filename                                Type            Size    Used    Priority
/dev/sda1                               partition       4200960 277680  0
/dev/sdb5                               partition       4194300 278724  0

# losetup -a
/dev/loop3: [0005]:158 (/dev/sda6) encryption=eme256
/dev/loop5: [0005]:157 (/dev/sda5) encryption=eme256

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