"here strings" and tmpfiles

[Daniel Kahn Gillmor]

hi bash developers--

I ran the following command to get a sense of how bash deals with here
strings under the hood:

    strace -o tmp/bash.herestring.strace -f bash -c 'cat <<<"hello there"'

(i'm testing with bash 5.0-2 on debian testing/unstable).

It turns out that this creates a temporary file, actually touching the
underlying filesystem:

    […]
    18557 openat(AT_FDCWD, "/home/dkg/tmp/sh-thd.UCPAvB", 
O_RDWR|O_CREAT|O_EXCL, 0600) = 3
    18557 fchmod(3, 0600)                   = 0
    18557 fcntl(3, F_SETFD, FD_CLOEXEC)     = 0
    18557 write(3, "hello there", 11)       = 11
    18557 write(3, "\n", 1)                 = 1
    18557 openat(AT_FDCWD, "/home/dkg/tmp/sh-thd.UCPAvB", O_RDONLY) = 4
    18557 close(3)                          = 0
    18557 unlink("/home/dkg/tmp/sh-thd.UCPAvB") = 0
    18557 fchmod(4, 0400)                   = 0
    18557 dup2(4, 0)                        = 0
    18557 close(4)                          = 0
    18557 execve("/bin/cat", ["cat"], 0x5577ec52b8e0 /* 49 vars */) = 0
    […]

I could find no mention in the bash(1) manpage of any risk of either
here documents or here strings touching the underlying filesystem.

I know that some systems use heredocs or herestrings explicitly to avoid
things like:

 * writing to the filesystem,
 * invoking extra processes, or
 * making sensitive data avaialble to the process table.

For example, sending a password or secret key material from the
environment to stdin would be a typical way to use a herestring.

So writing this stuff to the filesystem, where it is likely to touch the
underlying disk, seems particularly problematic. And of course there is
the potential for weird race conditions around filename selection common
to all tmpfile-style shenanigans.

A few possible options for trying to improve the situation:

 a) use socketpair(2) or pipe(2) instead of making a tmpfile.  this has
    the potential downside that the semantics of access to the remaining
    file descriptor would be subtly different from "regular file"
    semantics.

 b) On systems that support O_TMPFILE, try something like
    open("/dev/shm", O_RDWR|O_CREAT|O_EXCL|O_TMPFILE).  /dev/shm tends
    to be a globally-writable tmpfs, so that avoids touching any disk,
    and O_TMPFILE avoids tmpfile-style race conditions.  This might need
    a fallback (to the current tmpdir selection mechanics?) in case
    /dev/shm isn't available.

 c) Just use O_TMPFILE with the current tmpdir selection mechanics, if
    it's supported.  This isn't quite as clever as trying to use
    /dev/shm first, and it won't fix the herestrings hitting the disk,
    but it at least avoids tmpfile races.

 d) If none of the above can be done, at the very least, bash(1)'s
    section on here docs and here strings should warn that the contents
    of these documents are likely to get written to the disk
    unprotected.

Does this make sense?  If this has been raised and discussed elsewhere,
please don't hesitate to point me to any archives of that discussion.

Please keep me in cc during any replies, i'm not subscribed to
bug-bash@gnu.org.

Regards,

        --dkg

signature.asc
Description: PGP signature