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.lobe...@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@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
