Re: password-store /dev/shm mfs

David, thank you so much for the thorough historical explanation, I'm
learning a lot on this list!
I'm just an OpenBSD newbie, but
I've been using softraid crypto since my first installation. Just to be
sure.
As I tried to explain in my previous email, I've found a second solution
that doesn't imply creating/destroying mfs on each "pass edit". It leaves
/tmp permanently mounted as mfs in fstab (to reduce writes to my SSD). It
involves root only for creating/deleting a symbolic link named /dev/shm to
/tmp.
Probably, all this might not even be necessary in my set-up, because pass,
after the annoying warning, proceeds to write the file to /tmp anyway,
which in my case is on mfs.
If I understand it correctly, mfs is a sort of RAM disk and is therefore
erased when the computer is shut down.
Right?
David

Ps Perhaps what I'm writing is all newbie nonsense. In which case, I
apologize for my ignorance.

Il mer 12 ago 2026, 00:01 David Dahlberg <[email protected]> ha
scritto:

> David,
>
> Thanks for your explanation. I will come back to experiment with it, when
> I am back from holidays.
> I have to have another try updating my ports anyways.
>
> A bit of history:
>
> 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.
>
> 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:
>
> 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.
>
> 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?
>
> David
>