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?) -- Please keep replies on the mailing list.
