[OpenIndiana-discuss] recompiling a program for openindiana

[Marc Lobelle]

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