Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#29799 - [initscripts][cryptsetup] encrypted temporary filesystems

Attached to Project: Arch Linux
Opened by erdbeer (erdbeer) - Monday, 07 May 2012, 12:11 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 08 May 2012, 20:02 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I'd like to have encrypted temporary filesystems.

Patch for /etc/rc.d/functions:

How it works:
Write "TMP" in the password column in /etc/crypttab and add it in /etc/fstab. When the system boots, a new ext4 filesystem will be created.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Tuesday, 08 May 2012, 20:02 GMT
Reason for closing:  Deferred
Comment by Dave Reisner (falconindy) - Monday, 07 May 2012, 12:17 GMT
This doesn't really make any sense. It'll be created the first time, and then never again because of the blkid -p check you copied over.

- Why not just make the partition once yourself and add it to fstab/crypttab?
- Why ext4? Why not reiserfs? or ext3? or btrfs?
- What's the use case?
Comment by Tom Gundersen (tomegun) - Monday, 07 May 2012, 12:34 GMT
In principle we could do something like this (though I don't like the magic word "TMP", we should just figure out that this is the right thing to do based on the fact that the key is something like /dev/urandom).

That said, I'd like a clear usecase first. Why not just use a tmpfs for your temporary data, and add the partition you intended to encrypt as swapspace (which can be encrypted). That should give you the same level of security, as long as using a tmpfs is ok for you. In my experience using a swap-backed tmpfs is always preferable to a regular filesystem, but I'd be open to any tests that prove me wrong :-)
Comment by erdbeer (erdbeer) - Monday, 07 May 2012, 13:25 GMT
> - Why not just make the partition once yourself and add it to fstab/crypttab?
So you don't have to enter a password every time you boot.

> - Why ext4? Why not reiserfs? or ext3? or btrfs?
Why not ext4? I chose it because it is fast and reliable.

> - What's the use case?
There might be some people who don't have enough ram for a tmpfs and who don't want anything user-writable to be unencrypted on the disk. I've seen this feature in debian, so I thought there are people who use this (if not, why would they implement it?). A swap-backed tmpfs might work as well. Why is it preferable to a regular filesystem?
Comment by Tom Gundersen (tomegun) - Tuesday, 08 May 2012, 12:19 GMT
It seems to me that you could equally well use a tmpfs backed by encrypted swap.


* We already support this and don't have to add any code.

* You'll likely get higher performance. When using ext4 the kernel will write your data to disk frequently (as one aim is to avoid data-loss on a crash), on a tmpfs the data is only written to disk if you run out of ram (as the data is temporary and in case of a crash/reboot we want to throw it away anyway). See for some numbers from one usecase (obviously YMMV).

* Writing all your data to disk, only to delete it on reboot seems like a waste of time to me.


* If you are doing a lot of swapping, you might see reduced performance. This is because (allegedly) your data is deleted from disk when it moves from swap to ram, so if it must move back you need to write it again. Using ext4 the data will stay on disk, so if you have to evict it from memory no writing is needed. I have not seen any numbers on this, only heard it described. If it can be shown that this is a problem, we could consider implementing this FS (though I'd think it would be a lot nicer if the kernel's swap could be taught to do the right thing).

As to why Debian (and others) would implement encrypted tmp on ext4: until some kernel releases ago tmpfs had lots of limitations compared to other filesystems (limit on the size of files it could store, etc). These have been sorted out and these days it is just like any other filesystem.

Regarding the popularity of this feature: I pointed out a conceptual flaw in the systemd implementation (it is broken) a long time ago, and while fixing it was put on the TODO, no one seems to have complained about it nor has any resources been put towards fixing it. So I guess it is hardly used (if at all) on Fedora/OpenSUSE/+++.
Comment by erdbeer (erdbeer) - Tuesday, 08 May 2012, 19:53 GMT
Okay then, swap backed tmpfs seems fine to me now. Please close this feature request if you like to.
Comment by Tom Gundersen (tomegun) - Tuesday, 08 May 2012, 20:02 GMT
If anyone wants to reopen this in the future: We'll consider it if you have performance numbers to back it up :-)