[OpenIndiana-discuss] recompiling a program for openindiana

Mon Nov 27 10:28:15 UTC 2017

Hi Marc

That setup is overkill suicide. It will bite you more than be usefull.
The basic Zpool already has Failure Protection and stuff built in. If
you want to do a raidz do it on the base pool.

As for the Importing. If you have closed the lofi device you should not
see it. You have to reopen the lofidevice and then import it with path.

If you destroy a zpool its contents will be destroyed. Thats the point
of destroy.

The most simple setup is ZPOOL -> ZFSVolume -> LofiCrypto -> UFS Filesystem.

You can also make a File on a Dataset but it will bring you no benefits
compared to a ZFS volume.

This Setup should work. And it avoids all the pitfalls with
import/export you are mentioning.

A Simple Mount is enough (and ofcourse setup lofiCrypt)

Hope this helps
Greetings
Till

On 27.11.2017 01:11, Marc Lobelle wrote:
> Hello Till,
> 
> On 26/11/17 22:53, Till Wegmüller wrote:
>> Hmm
>>
>> I am affraid several Unix Machanisms block you here.
>>
>> First mount was designed so that a filesystem that is in access can not
>> be unmounted. This so that an admin can not accidentally kill the system
>> with an umount. I am not aware of a filesystem based mechanism that
>> leaves the access once the file is written, AFAIK this is also true on
>> linux with DMcrypt. This kind of design only works with an file based
>> approach like GPG/PGP.
>>
>> If you have a Zpool inside the Lofidevice you will have to deactivate it
>> and all process using it before closing the lofidev.
> Indeed, this is the clean way to do it
>>
>> Zpools can be imported and mounted during import/export they are
>> automatically mounted/unmounted.
> I tried to do that but I did not find how to import a whole raidz2 of
> encrypted lofi files after exporting it
> 
> I tried to export it: that works but if I then type zpool import, I do
> not see it and if I try to reimport it? i get a message that it does not
> exist
> If this can be done, the zpool could indeed be cleanly unmounted and
> later remounted
> That would be equivalent to the encrypted zfs file systems on solaris
> that I use on other computers.
> What do you think ?
> Thanks
> 
> Marc
>> The In use limitation applies to both
>> aswell due to forementioned reason.
>>
>>  From what i gather what you want you may want to look at the F.U.S.E
>> Options.
>>
>> I have a bit of trouble figuring out your threat model. Could you
>> elaborate on what you want to defend against? This may allow people to
>> give you better advice.
> I want the file system to be encrypted but to be able to mount it at
> will (giving the passphrase) when I need to use it or to unmount it when
> I do not need it.
> Another question is: If the zpool is exported, can the lofidev be closed
> ? If I destroy the zpool, I  can close the lofidev and later reopen them
> and rebuild the zpool but the contents is lost.
> 
> Marc
>>
>>
>> Greetings
>> Till
>>
>> On 25.11.2017 16:11, Marc Lobelle wrote:
>>> Dear Till,
>>>
>>> I used the technique of Constantin [2] and, with a script to automate
>>> the lofi commands, it works really fine. When the system boots, the
>>> encrypted pool is not usable and after running the script, it becomes
>>> visible.
>>> However I did not manage to close the access to the encrypted pool
>>> without rebooting the system: if I try "lofiadm -d" to block access to
>>> the files through lofi, the system refuses because the devices are busy
>>> and it would cause a fault, which is exactly wat I want.
>>> Do you know a way to do that?
>>> I tried to zpool export the encrypted zpool, but I cannot reimport it
>>> after disconnecting then reconnecting the lofi's.
>>>
>>> Thanks in advance for your advice
>>>
>>> Best regards
>>>
>>> Marc
>>>
>>> On 20/11/17 09:36, Till Wegmüller wrote:
>>>> You can use Lofi dev to encrypt the device below the filesystem Layer.
>>>> [1] [2] [3]
>>>>
>>>> You can use a container Solution I.e A ZFS Volume that is encrypted
>>>> with
>>>> lofidev and then has an UFS Partition inside. Somewhat like [2] but
>>>> with
>>>> UFS rather than ZFS inside the Volume.
>>>>
>>>> Or you could help review the Encryption code for upstreaming. It is
>>>> already written but in Process of upstreaming. I think it's [4] but you
>>>> will have to search from there further.
>>>>
>>>> [1]
>>>> https://blogs.oracle.com/darren/encrypting-zfs-pools-using-lofi-crypto
>>>> [2]
>>>> https://constantin.glez.de/2012/02/27/introducing-sparse-encrypted-zfs-pools/
>>>>
>>>>
>>>> [3] https://napp-it.org/extensions/encryption.html
>>>> [4] https://github.com/openzfs/openzfs/pull/124
>>>>
>>>> ---
>>>> Greetings
>>>> Till
>>>>
>>>>
>>>> On 20.11.2017 10:51, Marc Lobelle wrote:
>>>>> On 20/11/17 09:06, Peter Tribble wrote:
>>>>>> On Mon, Nov 20, 2017 at 9:02 AM, Marc
>>>>>> Lobelle<marc.lobelle at uclouvain.be>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am trying to recompile a program called srm (available on
>>>>>>> sourceforge )
>>>>>>> for openindiana. It works as rm but makes sure that there is no
>>>>>>> trace of
>>>>>>> the destroyed file in the blocks of the free list.
>>>>>>> This program uses #if defined (__linux__) and  #if defined
>>>>>>> (__OpenBSD__)
>>>>>>> and I should replace this code with something appropriate for
>>>>>>> openindiana.
>>>>>>> __linux__ etc are predifines preprocessor macros, presented in
>>>>>>>
>>>>>>> https://sourceforge.net/p/predef/wiki/OperatingSystems/
>>>>>>>
>>>>>>> However, I do not see openindiana in there, so what should I use ?
>>>>>>>
>>>>>> Note that if you're using ZFS (which is the default file system on
>>>>>> OpenIndiana) then
>>>>>> the overwriting which srm does will have no effect - the
>>>>>> copy-on-write
>>>>>> mechanism
>>>>>> that ZFS uses for data integrity ensures that the "overwrite" will go
>>>>>> to a
>>>>>> different,
>>>>>> unused, part of the device. Therefore, srm won't do any good.
>>>>> Hum, this means that bcrypt will not erase the original file after
>>>>> encrypying it either and the file must be decrypted to be used. How
>>>>> can
>>>>> I make sure that its contents cannot be recovered on zfs then ? (apart
>>>>> from writing the zfs encryption code that is missing in illumos zfs
>>>>> ; it
>>>>> will have to be done eventually but I'm looking for an interim
>>>>> solution).
>>>>>
>>>>> Thanks
>>>>>
>>>>> Marc
>>>>>
>>>>> _______________________________________________
>>>>> openindiana-discuss mailing list
>>>>> openindiana-discuss at openindiana.org
>>>>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>>>> _______________________________________________
>>>> openindiana-discuss mailing list
>>>> openindiana-discuss at openindiana.org
>>>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>>>
>>> _______________________________________________
>>> openindiana-discuss mailing list
>>> openindiana-discuss at openindiana.org
>>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>> _______________________________________________
>> openindiana-discuss mailing list
>> openindiana-discuss at openindiana.org
>> https://openindiana.org/mailman/listinfo/openindiana-discuss
> 
> 
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss