RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 613982 - hald blocks temporary-cryptsetup devices (again)
Summary: hald blocks temporary-cryptsetup devices (again)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: hal
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Richard Hughes
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On: 613909
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-13 12:40 UTC by Milan Broz
Modified: 2013-03-01 04:09 UTC (History)
8 users (show)

Fixed In Version: hal-0.5.14-8.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 613909
Environment:
Last Closed: 2010-11-15 13:58:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Milan Broz 2010-07-13 12:40:57 UTC
+++ This bug was initially created as a clone of Bug #613909 +++

The same problem is in RHEL6

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.)

Version-Release number of selected component (if applicable):
hal-0.5.14-6.el6.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).

--- Additional comment from mbroz on 2010-07-13 06:48:30 EDT ---

Created an attachment (id=431413)
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.

--- Additional comment from prajnoha on 2010-07-13 07:05:34 EDT ---

(In reply to comment #1)
> (Peter can say exact version).

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

--- Additional comment from prajnoha on 2010-07-13 07:07:51 EDT ---

(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 :)

--- Additional comment from rhughes on 2010-07-13 07:44:12 EDT ---

(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.

--- Additional comment from mbroz on 2010-07-13 08:11:51 EDT ---

Done, I hope it is correct list :-)
http://article.gmane.org/gmane.linux.hotplug.devel/15936

Comment 4 Vladimir Benes 2010-08-30 12:36:20 UTC
verified by reporter.. setting Verified flag to Customer as it was verified by non QE @redhat.com member

Comment 5 releng-rhel@redhat.com 2010-11-15 13:58:55 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


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