Re: "here strings" and tmpfiles

[Daniel Kahn Gillmor]

On Mon 2019-03-18 17:18:10 -0400, Daniel Kahn Gillmor wrote:
> 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.

One more possibility for an implementation fix occurs to me (at least on
systems with Linux >= 3.17 and glibc >= 2.27):

 e) bash could use use memfd_create(2) for heredocs and herestrings --
    that should preserve "regular file" semantics, avoid tmpfile races,
    and avoid hitting the disks.

    --dkg

signature.asc
Description: PGP signature