bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "here strings" and tmpfiles


From: Chet Ramey
Subject: Re: "here strings" and tmpfiles
Date: Wed, 10 Apr 2019 09:07:27 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 4/9/19 2:56 AM, Jason A. Donenfeld wrote:
> Since originally raising this issue with dkg (leading to this email
> thread), I've only followed along from a bit of a distance. But it does
> look like there's been some good progress: there's now a commit that
> fills the pipe up to the OS's maximum pipe size, and then falls back to
> the old (buggy, vulnerable, scary) behavior. 

This is unnecessary hyperbole. The existing file-based mechanism works
just fine. We're talking about what's essentially an optimization.


> Seems like there are several
> problems with this approach:
> 
>   - Determining the maximum pipe size at build time doesn't make sense
>     for systems where such a thing is actually determined (and adjustable)
>     at runtime.

The alternative is to use PIPE_BUF, which would be fine but throw away a
lot of possible uses. For instance, my Mac OS X system has a pipe capacity
of 64K, but PIPE_BUF is set to 512 bytes. There are a lot of scripts that
could take advantage of that difference to use pipes.

>   - The security of this language construct is now OS and runtime-
>     configuration dependent. That means it's not that reliable, and so
>     we're basically back at advising square one: "don't use herestrings".

This doesn't make any sense.

> 
>   - If user-supplied input is used in a herestring, the user now controls
>     whether the secure path or the insecure path is used.

There isn't an "insecure path."

> 
> A real solution for this issue involves getting rid of the temporary file
> all together. Since we're talking about a bash string, it's already in
> memory. Why not just fork() if the write() will block? A simple way would be
> to always fork(). A fancy way would be to set NONBLOCK mode, see if it
> returns EAGAIN, and only fork() if the write would block. Either way seem
> basically fine, with the critical part being that the temporary file is
> totally gone from the equation.

If someone would like to take the code in the devel branch and add this, I
would certainly look at it.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]