On Tue, Mar 15, 2022 at 3:34 PM Markus Schade <[email protected]> wrote:
> Am 14.03.2022 um 17:02 schrieb Bryan Smith: > > On Sun, Mar 13, 2022 at 4:33 PM Markus Schade via lpi-examdev > > <[email protected] <mailto:[email protected]>> wrote: > > > > I am kind of missing any encryption. Whether it be fscript (ext4), > > ecryptfs, gocryptfs or cryfs. > > > > Right now, in Objective 203.3, it's limited to creating/configuring the > > kernel DeviceMapper (DM) facilities, such as Linux Unified Key Setup > > (LUKS). *[201-203]* > > > > Definitely interested in knowing more about where LUKS is too limited in > > scope, whether other solutions volume/file system-based (possibly same > > section), or file/virtual-volume (possibly another section). > > My view is limited and just as biased as yours. Ext4 fscrypt is a consideration. I was reading up on it, and how it should be faster. Unfortunately it doesn't seem to be, and 'any filesystem/volume' generic support afforded by DeviceMapper (LUKS, dm-crypt) seems to be faster. This is likely because it's working on block-based access in the kernel. *[1]* eCryptfs I'm not very familiar with. I'm trying to find out more information on how it differs, but it seems to be system-level, and not end-user too? goCryptfs, on the other hand, seems to be an 100% end-user, file-based, not a volume or filesystem encryption. It doesn't require root. QUOTE: *_'As a FUSE filesystem, gocryptfs is fully configurable by the user and stores its configuration files in the user's directory paths.'_* So I'm not sure this is really a Senior Sysadmin level consideration. There are so many end-user tools, many open source. > What I see is that storage is often just a public/cloud service. Such services often file/object based. Whether it be S3, WebDav, (s)FTP, or one of the > proprietary services like Onedrive, GDrive, etc. > Again, like goCryptfs, those aren't as much of an inherent, system-level, Linux volume/file system detail. Not sure if we want to be looking at these types of end-user options in LPIC-2. Maybe LPIC-1? Storage exam? > And the other use case is when files need to be access directly and/or > randomly. Here you see the likes of rclone or ecryptfs,gocryptfs,etc. > over fuse mounts. > Again, not really thinking this is LPIC-2 relevant. LUKS is not really the usable for those cases. > End-user solutions never are. But so many exist. So many are open source. LUKS works with TPM hardware, and anything else that is DeviceMapper accessed. It is well supported as a generic block/volume encryption for anything stored in those volumes, including any Linux file systems. If there is a case to be made for similar, system-level encryption, I'm all ears. Ext4 fsCrypt and, possibly, eCryptfs are candidates, since they work similarly. Market surveys may be in order. But end-user, not so sure. Probably something more for Containers, DevOps or dedicated Storage exam? - bjs [1] Ext4 fscrypt v. LUKS (v. eCryptfs) - https://www.phoronix.com/scan.php?page=article&item=ext4-crypto-418&num=2 -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
