Milan Broz schrieb:
Hi Thomas, currently there is discussion between dm/lvm developers and some maintainers how to unify DM udev rules so these problems are fixed definitely. (Final state should be that applications using libdevmapper will use udev to create nodes and unified udev rules are part of libdevmapper package.) CCing Peter - I am sure he can explain your questions better than me.
I would be very interested in this, I'll look up the discussion.
Then I suggested adding the following udev rule (which I will probably make the default): ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="dm-[0-9]*", PROGRAM="/sbin/dmsetup info -c --noopencount --noheadings -o name -j %M -m %m", RESULT=="temporary-cryptsetup-*", OPTIONS="last_rule" (btw, is there a better way than calling dmsetup to get the name here?).BTW for recent kernel, name and UUID is in sysfs directly. We have already some rule in dm package.
$ cat /sys/block/dm-0/dm/name lvm_pv $ cat /sys/block/dm-0/dm/suspended 0 $ cat /sys/block/dm-0/dm/uuid CRYPT-4e80f75b-77d2-465c-ba8c-9480493dd717This is awesome. How new does the kernel have to be? Some people are forcing me to support ancient kernels (like 2.6.27), while personally I'd rather only support latest stable.
Now, this fixes the problem with 1.0.7, as it prevents devicekit from blocking access to the device, but the above error message isn't gone in 1.1.0: http://bugs.archlinux.org/task/16735#comment51536 What is this remove error caused by, if not by some application being called from udev blocking access? Note that there are no temporary-cryptsetup-* volumes left after luksOpen.No idea - but always I debubugged it, it was initiated from udev event through udev rule.
The rule above should effectively keep udev from spawning any process that will do anything to the device - but yes, we need to debug it. I have to see if I can set up a test case on the weekend so I can debug this - until now, I have not seen this problem myself.
I'll add better debug message to next cryptsetup rc (including process + parent process name, I hope I can get it from /proc in debugging mode) into debug output to allow more easy debugging of that problem - I do not want to hide it by some workaround, it must be fixed. (Surely nobody want an application randomly reading opened, decrypted internal keyslot device.)
That would be great. For now I am happy that the affected users have working computers again :)
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
