Bug 613909 - hald blocks temporary-cryptsetup devices (again)
Summary: hald blocks temporary-cryptsetup devices (again)
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
(Show other bugs)
Version: 14
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 614989 (view as bug list)
Depends On:
Blocks: 613982
TreeView+ depends on / blocked
 
Reported: 2010-07-13 08:17 UTC by Milan Broz
Modified: 2013-03-01 04:09 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 613982 (view as bug list)
Environment:
Last Closed: 2012-08-16 19:59:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch/workaround (472 bytes, patch)
2010-07-13 10:48 UTC, Milan Broz
no flags Details | Diff
Log of the rsync/verify process failing (4.85 KB, text/plain)
2011-08-21 20:37 UTC, Johan Vromans
no flags Details

Description Milan Broz 2010-07-13 08:17:19 UTC
Description of problem:
LUKS device need during opening temporary device which contains obfuctated master key. This device is marked private (with all udev flags) and nobody must read from this device except cryptsetup itself.

IIRC there was a workaround in HAL, which excluded temporary-cryptsetup-* devices, unfortunately this workaround now doesn't work, because device node changed and /dev/mapper/temporary-* is now symlink to /dev/dm-X device.
(This change was requested by udev upstream when integrating udev in DM.)

You should parse /sys/block/dm-X/dm/name (or use DM_UUID which is CRYPT-TEMP-*) instead of parsing node name or used udev variable like other rules do.

The same bug appeared in Debian, see my comment there http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586286#40

Version-Release number of selected component (if applicable):
hal-0.5.14-3.fc14.x86_64

How reproducible:
cryptsetup luksOpen for some device on rawhide.

Sometimes, when hal i sreally slow in scan, you can see in --debug this:
# cryptsetup 1.1.3 processing "cryptsetup luksOpen /dev/sdb2 x --debug
...
# dm remove temporary-cryptsetup-16370  OF   [16384]
device-mapper: remove ioctl failed: Device or resource busy
...
# WARNING: other process locked internal device temporary-cryptsetup-16370, retrying remove.
# WARNING: Process PID 16374 (hald-probe-volu) [PPID 1277 (hald-runner)] spying on internal device /dev/dm-6.

Expected results:
Nobody must touch crytsetup internal device, it contains obfuscated key. Moreover it blocks cryptsetup from operation (it will recover but with error messages).

Comment 1 Milan Broz 2010-07-13 10:48:30 UTC
Created attachment 431413 [details]
proposed patch/workaround

Proposed patch checks flag which udev rules set for internal devices. It should work with all new udev rules (Peter can say exact version).

Please apply this, thanks.

Comment 2 Peter Rajnoha 2010-07-13 11:05:34 UTC
(In reply to comment #1)
> (Peter can say exact version).

That should be lvm2 v2.02.54 (device-mapper v2.02.39).

Comment 3 Peter Rajnoha 2010-07-13 11:07:51 UTC
(In reply to comment #2)
> That should be lvm2 v2.02.54 (device-mapper v2.02.39).

..ehm, device-mapper v1.02.39, I mean :)

Comment 4 Richard Hughes 2010-07-13 11:44:12 UTC
(In reply to comment #1)
> Created an attachment (id=431413) [details]
> proposed patch/workaround
> 
> Proposed patch checks flag which udev rules set for internal devices. It should
> work with all new udev rules (Peter can say exact version).
> 
> Please apply this, thanks.    

Looks okay to me, but could you please send this to the upstream hal mailing list and then I'll ack it, and commit it upstream as well.

Thanks.

Richard.

Comment 5 Milan Broz 2010-07-13 12:11:51 UTC
Done, I hope it is correct list :-)
http://article.gmane.org/gmane.linux.hotplug.devel/15936

Comment 6 Michael Biebl 2010-07-13 13:58:06 UTC
Hi Milan, the hal mailing list is at
http://lists.freedesktop.org/mailman/listinfo/hal

Comment 7 Milan Broz 2010-07-13 14:10:21 UTC
(In reply to comment #6)
> http://lists.freedesktop.org/mailman/listinfo/hal    
thanks, resent there but list is moderated, so waiting for in queue...

Comment 8 Milan Broz 2010-07-16 09:49:00 UTC
*** Bug 614989 has been marked as a duplicate of this bug. ***

Comment 9 Bug Zapper 2010-07-30 12:32:37 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 10 Milan Broz 2010-08-03 14:10:07 UTC
Any progress here?

Comment 11 Johan Vromans 2011-08-21 20:35:05 UTC
I'm raising severity: it's not just an anoying message, it seems to cause disk corruption.

My setup:
- I'm running Fedora 14 with all updates.
- I create incremental backups of partitions
- I mount an encrypted USB stick
- I rsync the incrementals to the USB stick
- I cmp the original data with the new data (actually this is a left-over from the time I copied the data to tape -- for which I'm grateful)

Since a couple of days I get the message "device-mapper: remove ioctl failed: Device or resource busy" while mounting the encrypted USB stick, and in the end the verification fails.
Investigation shows that the data that rsync writes to the USB stick is corrupted. This is reproducible, though the exact corruption differs. I tried several USB sticks, reformatted them and so on. Still no success.

When I run this procedure with HAL disabled, there's no "device-mapper" message and rsync and verification complete without problems.

I have attached the log of the copy/compare process.

The backup copy and verify process has been in production for a couple of years and never showed any signs of strange failures. I cannot explain why the failures started on August 19. I did perform a system update on August 16, but if this was the cause I'd expect failures starting August 17, not a few days later.

Since I use encrypted disks for several purposes, I'm very worried.

Comment 12 Johan Vromans 2011-08-21 20:37:11 UTC
Created attachment 519202 [details]
Log of the rsync/verify process failing

Comment 13 Fedora End Of Life 2012-08-16 19:59:05 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


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