[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 chet@case.edu http://tiswww.cwru.edu/~chet/
- Re: "here strings" and tmpfiles, (continued)
- Re: "here strings" and tmpfiles, Greg Wooledge, 2019/04/10
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/10
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/10
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/10
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/10
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/11
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/12
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/12
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/10
- Re: "here strings" and tmpfiles, Jason A. Donenfeld, 2019/04/09
- Re: "here strings" and tmpfiles,
Chet Ramey <=
- Re: "here strings" and tmpfiles, Daniel Kahn Gillmor, 2019/04/10
- Re: "here strings" and tmpfiles, Greg Wooledge, 2019/04/10
- Re: "here strings" and tmpfiles, Peter & Kelly Passchier, 2019/04/10
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/10
- Re: "here strings" and tmpfiles, Daniel Kahn Gillmor, 2019/04/10
- Re: "here strings" and tmpfiles, Andreas Schwab, 2019/04/11
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/11
- Re: "here strings" and tmpfiles, Greg Wooledge, 2019/04/11
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/11
- Re: "here strings" and tmpfiles, Andreas Kusalananda Kähäri, 2019/04/11