From: Chris Billington Subject: Re: password-store /dev/shm mfs To: Stuart Henderson Cc: openbsd-ports Mailing List Date: Wed, 12 Aug 2026 14:20:16 +0800 Stuart Henderson wrote: > On 2026-08-11, David Dahlberg 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?) > If password-store finds /dev/shm, whether backed by an mfs or not, it only does an 'rm -rf $SECURE_TMPDIR' instead of 'rm -P ' followed by that command, as it does if using /tmp. So potentially if the system comes under memory pressure, the unlinked unencrypted blocks could end up being swapped to disk? Depending on use case, 'rm -P' might be sufficient security for many users. Disk encryption offers further protection, though in some jurisdictions (UK is one), if the right magic words are uttered by the authorities, it's a criminal offence not to give up the passkeys for encrypted devices on demand. Or under threat of the proverbial rubber hose from just anyone. I am testing out mounting a 2MB mfs under ~/.password-store/tmp, (700 perms) and mounting it at boot in /etc/fstab. TMPFILE is exported in ~/.xsession so that pass uses the mfs. Can anyone see problems with that approach? Does it offer anything over 'rm -P' in /tmp/$SECURE_TMPDIR? I am not sure it does. In that scenario, the warning about /dev/shm is redundant, and could potentially be patched out. FreeBSD chose to just patch out the warning: [https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244470&action=edit], and left it to the user to decide what to do. Chris