On Sun, December 30, 2012 11:53, Arno Wagner wrote: > On Sun, Dec 30, 2012 at 10:39:43AM +0100, Milan Broz wrote: >> On 12/30/2012 09:42 AM, Sven Eschenberg wrote: >> > Hi Milan, >> > >> > What happens though, if signatures are not accessible during >> luksFormat? >> > (Or alternatively, are not found, because they are misaligned from the >> > current setup's perspective?) >> > >> > Scenario, create a md volume with 1.0 metadata (end of device), start >> md >> > device, do luks format. >> >> Well, there are priorities but in fact these configurations need some >> external info (or admin knowledge). > > Indeed. Just added the warning that previosuly used partitions should > be wiped to the man-page of cryptsetup. I also found that "wipefs" > does not remove matadata 0.90 signatures from md components (located > at the end. I still use them because I like kernel-level autodetection > and my arrays are small), also added warning about that. Seems like the most reasonable solution to add this bit to the man page. btw, it is called wipefs, not wipeall metadata ;-) (SCNR). I think we can agree, that if a reasonable person gets reminded to wipe problematic data, the person can take care of this. I think mdadm --zero-superblock will work for 0.9 (Only used it on v1.x versions so far). > >> > Now, in intial unused state, the luks header and md metadata is >> visible. >> > While cryptsetup might be able to realize that the md device should >> first >> > be started, this might not be true for all tools (unfortunately). >> Possible >> > similiar scenarions with leftover superblocks etc. can surely be >> created. >> >> Yes, and in the MD format (end of device) case the problem repeats >> very often. > > Indeed. See above. > >> > I am aware this is a specific case due to the end of device policy of >> the >> > md metada v1.0. What I am trying to say is, not all cases can >> > automagically be resolved, sometimes the knowledge and interaction of >> an >> > admin might really be required. And for educated guessing, the admin >> needs >> > to be educated beforehand ;-). >> >> Yes, fully agree. I can mention other situations, which can be >> configured >> this way (LVM has several such undocumented scenarios) where you cannot >> automatically say which signature is the first... > > I think warning the user that anything previously used need to be > cleaned is enough. FAQ and man-page do that now. I think that is > enough. Those that do not read documentation will always find some > way to shoot themselves in the foot... As said before, I second that. > >> (I can write very long description about plans about "block device >> assembly" library under util-linux project which should help to solve >> this, but I am afraid that I will not work on this project anymore.) > > Some magic pressure-cooker you throw some partitions in and > get some assembled and runnign filesystems out? Sounds like > a nightmare to implement ;-) Or a nightmare to use if anything backfires ;-). > >> And because we are on dmcrypt list - there is always need from security >> (or paranoid ;) people to separate or hide metadata (e.g. LUKS header >> or >> hidden container). In this situation you simply must know some info in >> advance to properly activate such storage... > > Security requires understanding what you are doing or at least reading > the documentation carefully (it it is any good). For example, I > recently found out that there are people that run TrueCrypt on Windows > whith hibernation active and the hibernation file not on an encrypted > device. That is a complete fail, as the encryption keys then go into > the hiberfile. (The documentation warns about this.) Seems you can > even buy software that recovers the keys automatically. > > Arno > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D > 9718 > ---- > One of the painful things about our time is that those who feel certainty > are stupid, and those with any imagination and understanding are filled > with doubt and indecision. -- Bertrand Russell > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > -Sven _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
