+++ 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 on 2011-02-21 09:51:51 EST --- Dan? --- Additional comment from dwalsh 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 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 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 on 2011-02-23 11:32:28 EST --- But still, this happens in permissive mode as Matej wrote above. --- Additional comment from mgrepl 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.
Hmm, why did this get duplicated against systemd? This needs a policy change, no change in systemd. Or am I missing something?
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.
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?
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:
Matej, yupp, this is the LVm problem: E: UDISKS_PRESENTATION_NOPOLICY=1 E: SYSTEMD_READY=0.
*** This bug has been marked as a duplicate of bug 679321 ***
(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.
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"
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).
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.
Fixed in systemd git, upload will follow shortly.
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?
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...
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).
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
Yes, this really have been fixed. Thank you
systemd-20-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/systemd-20-1.fc15
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.
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