Re: [gentoo-user] LVM and moving things around

[Dale]

Michael wrote:
> On Monday, 28 March 2022 04:59:04 BST Dale wrote:
>> Michael wrote:
>>> On Sunday, 27 March 2022 22:04:45 BST Dale wrote:
>>>> That's sort of what I'm going to do.  I'm going to divide things into
>>>> sections with some encrypted and some not.
>>> I wonder if all you want to do is to encrypt some directories on your
>>> /home, then a different level of encryption would be more appropriate?
>>> Instead of encrypting a whole block device, you could just encrypt a
>>> directory tree or two, using ext4 encryption.  e4crypt has been kicking
>>> around for a few years now and it is meant to be an improvement on
>>> eCryptfs.
>>>
>>> https://lwn.net/Articles/639427/
>>>
>>> https://wiki.gentoo.org/wiki/Ext4_encryption
>>>
>>> WARNING:  I'm not qualified to speak about this topic because my
>>> experience is limited, but I'm interested all the same in reading your
>>> approach and other contributors advice.
>> That is the basic plan.  I'll have /home as a normal open mount point.
>> That way I can login without a encryption password being needed.  After
>> that, I plan to have other mount point(s) that are encrypted.
> OK, that's a different plan to what I'm talking about.  I am talking about
> filesystem based encryption.
>
> You are talking about block device level encryption.  Whether these other
> mountpoints you want to encrypt are for normal partitions, LVM, what-ever,
> you're dealing with whole block devices and mechanisms for encrypting these
> block devices *before* a filesystem and data is even placed on them.
>
> With a filesystem level encryption you will be using the kernel's native
> filesystem encryption and the fscrypt API to manage it.  The sys-fs/fscrypt
> userspace package can be used to manage the kernel based fscrypt API to
> encrypt/decrypt some directories selectively within a filesystem.  This can be
> set up to happen transparently via PAM, using the user's login, if desired.
>
> You can read more about the kernel fscrypt mechanism here:
>
> https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html
>
> For how to set it up and run it from userspace details are here:
>
> https://wiki.archlinux.org/title/Fscrypt
>
>
>> It may be
>> /home/dale/Data or something to that effect.  I'm still doing some
>> checking but the normal non-encrypted stuff should easily fit on a 6TB
>> drive without encryption.  I can then rebuild the two 8TB drives as
>> encrypted mount points with a different volume group thingy.  When I
>> boot up, I can login in as usual then decrypt the other mount point and
>> access it as needed or close it and it be encrypted until needed.
> If you have 8TB of data you want encrypted, then a block level encryption
> would make sense.  However, if you only have a few MB or GB of data to encrypt
> in a couple of directories, then it may be more appropriate to consider native
> filesystem encryption with fscrypt.
>
>
>> I've considered just encrypting /home completely but I don't have the
>> option of closing it while I'm logged into KDE.  KDE wouldn't be able to
>> access /home/dale/.kde or .config plus if I leave Seamonkey open, it
>> will want to store new emails to .mozilla as well.  So, some things need
>> to be available and I'm not to worried about them being encrypted
>> anyway.  So encrypting all of /home would be overkill plus would be a
>> problem for some things too, such as Seamonkey and KDE.
> With fscrypt you can run manually 'fscrypt lock Vault-for-Dale' and only the
> directory 'Vault-for-Dale' with any files in it will be encrypted.  All the
> remaining fs will be left as it was.
>
> Anyway, I'm only mentioning this as an alternative to consider, in case it fits
> your use case better than buying more disks and whole block device encryption
> methods.


I do that with another tool on occasion.  Usually, it is a directory
that has banking info etc in it.  I just right click and tell it to
encrypt it.  It uses the same password as my encrypted email program. 
The claim is it is secure. 

Given the large sizes tho, doing this way seems best.  Even the tool I
use for small stuff wouldn't work well. 

I googled and was trying to find info on how long it will take to shrink
from 20TB to around 12TBs or so.  It didn't lead to much except for
someone with some seriously large drives and it taking about a week to
shrink.  That's a problem.  If it will even take a few hours, I need a
new plan.  Anyone have ideas on how long that will take?

Dale

:-)  :-)