On 2026-08-11, David Dahlberg <[email protected]> wrote:
A couple of years ago, we had tmpfs(8), which I used in the
password-store port as a substitute for /dev/shm. tmpfs(8) was removed
in favour of mfs(8), but mfs has the disadvantage (for the pass
use-case) that it requires root. So creating/destroying a mfs on each
`pass edit` is not really viable.
there's no difference between tmpfs and mfs, you need root to mount.
Writing a ports readme about creating a mfs at /dev/shm is something that could
definitively be done, but lets try to recap at what Jason tried to achieve with
writing temp files in /dev/shm:
/dev/shm on recent linux is typically mounted as a memory filesystem, it
is meant to provide a backing store for the FDs used for posix shared
memory. (openbsd uses /tmp as a backing store for the same thing, with
extra bits in /etc/daily to avoid removing them by mistake..)
some software like pass (ab)uses this fs to store other files that they
want to keep from hitting persistent storage.
Pass requires a temp file for editing, as it works with files and your
favourite $EDITOR, which also required files. Jason was not happy with just and
removing a file since flash memory might use wear levelling and rm -P/shred
might overwrite a different physical block.
So if you have a privileged attacker, they can read your tempfile while it is
not yet deleted and you're screwed anyways. If you‘re working on ramdisk or
classic magnetic memory, youre probably okay. If your're on softraid crypto,
you're also okay, since the attacker would either need the key, or get
privileged access, but then we're back at 1.
If you have a privileged attacker, there are plenty more ways you're
scrwed. They can modify the password-store shell script or the programs
it calls, or look for pids running password-store and enable ktrace or
something.
So if I got this right, mfs may help you exactly when you're working on
unencrypted ssd/flash and the attacker may get physical access to the media.
Correct?
Honestly, if physical access is the threat, I'd recommend to encrypt your disk,
rather than using mfs just for deleted temporary password files. But FDE would
not silence the warning. Of course, I could patch this warning out - but in
some edge cases, there MIGHT indeed be a risk, and IMHO users should know.
What do you think?
I think that if password-store cares about this, it should check the
filesystem type rather than the path.
Piggybacking on a mechanism which is meant for something else entirely
doesn't seem too helpful either.
It would be helpful if it let you specify a path under which it
creates a random-named subdir and in that case (under the assumption
that you would only tell it that a dir is 'safe' if it is safe),
but it looks like it can't do that. (IIUC it will create a random
subdir under /dev/shm if SECURE_TMPDIR is unset, but if you pass it
a dir it skips the subdir).
(Also I suspect this is mostly theatre, who that cares that much about
this will be using a bash script to manage passwords in the first place?)
