[Pkg-cryptsetup-devel] Implementing a robust check-system

Jonas Meurer jonas at freesources.org
Sat Feb 4 19:50:05 UTC 2006

On 04/02/2006 gebi at sbox.tugraz.at wrote:
> ok sorry, i'll switch to german here (sorry others):
> Was ich damit gemeint habe war folgendes:
> Es ist sehr schwer auf eine Menge mit unbekannt vielen Teilen zu prüfen  
> und zu hoffen, dass man keines davon findet. Wenn man keines davon  
> findet denkt man es ist alles in Ordnung.
> Die checks werden also niemals sehr effektiv sein, weil es zu viele  
> Möglichkeiten gibt und wir nicht checken müssen ob eine spezielle  
> vorkommt, sondern wir alle checken müssen und wenn wir mit unseren  
> checks keine gefunden haben hoffen müssen ob wir nicht doch ein paar  
> dateisysteme in den checks übersehen haben.
> Deswegen die anmerkung mit dem softwaretesten. Wenn man eine software  
> testet und fehler findet, heißt es nicht dass sie fehlerfrei ist. Wenn  
> man sich das jetzt auf unseren Fall umgelegt vorstellt, dann hoffen  
> wir auf die Tatsache, dass die Software nach unseren Checks fehlerfrei  
> ist.
> Wir können niemals alle möglichen checks für Dateisysteme und  
> kombinationen implementieren, aber die sicherheit beruht darauf, dass  
> wir alle kombinationen kennen und damit ausschließen können dass auf der  
> partition ein dateisystem ist.
> Ist es jetzt ein bisschen klarer wieso ich mich um diese Checks so  
> drücken wollte?

yes, i understand your concerns, but still we have no other possibility
for cases like non-physical swap devices etc. i'dd agree with you that
providing such incomplete tests as default is silly.
but still i would provide them as optional ones. fsck -T at least checks
for all filesystems that fsck knows of, and i guess that this is enough
for now. don't you think so?

> >the check for partition type swap is not sufficient. it is possible to
> >use lvm volumes or whatever as swap partition, and these don't have any
> >partition type. you understand?
> >i think that it's a good idea to check for the partition type, and go
> >ahead if it is swap. but if it is not swap (because not a physical
> >partition at all) we cannot simply fail.
> Imho we can...
> If lvm/evms is not started the device does not exist and we should be fine.

you didn't understand my objections. imagine the situation, that lvm
_is_ started, and a logical volume is used as swap. this lv may have the
device /dev/vg00/swap. this is not a physical partition, therefore the
check for partition type will fail. but still it should be able to use
it as encrypted swap. therefore we need some possibility to allow swap
partitions on non-physical partitions.
that's why i'dd like to keep the option of a (incomplete) fs precheck.

> But you are quite right, we could introduce a precheck option in  
> crypttab to check against the most used filesystems under linux...
> But it should be clearly outlined, that the power of this check is  
> somewhat limited and does _NOT_ prevent dataloss under all  
> circumstances.

yes, that is what i'dd like to see ;-)
and i would not activate this precheck per default, only make it
optionally available.

> >- swap devices which are not a physical partition need to be supported.
> >  thus, the check for partition type cannot be the only one for swap.
> Swap devices wich are not on physical partitions are well supported  
> with this schema, because the lvm/evms device the user gave us simply  
> does not exist if lvm/evms is not allredy started.

but that's not the problem. if it exists, and the 'swap partition type'
check is run against it, the check will fail. and that is bad.

> >- the default for plain cryptsetup should be as you suggested, precheck
> >  is not default, but exists as a possible option.
> yes could be done, as a check for the most used filesystems under linux.
> But imho we should bring our users to the point where they give us a  
> postcheck for plain cryptsetup. Because only with this it's possible  
> to produce a reliable check for both ways (fals partition, false pw).


> I'll edit the dev docu accordingly.



More information about the Pkg-cryptsetup-devel mailing list