You are not logged in.

#1 2023-05-03 22:09:47

Registered: 2021-01-04
Posts: 9

Rationale for encrypted /tmp being backed by physical volume

On the wiki page which describes how to setup LUKS on LVM, part of process creates logical volumes for encrypted swap and tmp partitions. In particular, the logical volume, crypttmp, is backed by the physical volume of a disk. In the crypttab entry, we see the /dev/mapper/tmp device is initialised based on the crypttmp logical volume, before being mounted to /tmp as a tmpfs filesystem.

My understanding is that tmpfs filesystems are backed by RAM. So in this setting, why do we need to have the logical volume crypttmp backing it as well? Is the space allocated for crypttab by LVM actually used on disk? Or does all storage occur in RAM?

Last edited by steeps (2023-05-03 22:17:24)


#2 2023-05-03 22:47:49

Registered: 2013-11-15
Posts: 1,289

Re: Rationale for encrypted /tmp being backed by physical volume

You're right, the wiki is wrong. tmpfs is ram (but can be swapped out). It ignores the device argument or rather uses it as a literal name (dev, run, ...). So either the fstab should not be using tmpfs type here (ext4 or auto, I guess, unless a filesystem type was specified with tmp=type). Otherwise with tmpfs, the crypttab should not have a tmp entry at all.

You should be able to confirm this by making a checksum of the tmp device. That checksum should not change even if you put files in /tmp and sync (but it would change on reboot, since its encrypted with a different key each time, and formatted with a filesystem too). Furthermore the size is set to 500M in the wiki example, tmpfs size should be 50% RAM instead unless another limit was specified.

Last edited by frostschutz (2023-05-03 22:50:26)


Board footer

Powered by FluxBB