[OpenIndiana-discuss] recompiling a program for openindiana

[Till Wegmüller]

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.

Zpools can be imported and mounted during import/export they are
automatically mounted/unmounted. 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.


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