[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "here strings" and tmpfiles
From: |
Jason A. Donenfeld |
Subject: |
Re: "here strings" and tmpfiles |
Date: |
Thu, 11 Apr 2019 06:02:41 +0200 |
Hi Chet,
On Wed, Apr 10, 2019 at 3:07 PM Chet Ramey <chet.ramey@case.edu> wrote:
> This is unnecessary hyperbole. The existing file-based mechanism works
> just fine. We're talking about what's essentially an optimization.
> [...]
> This doesn't make any sense.
> [...]
> There isn't an "insecure path."
I'm a bit late to the thread, so apologies if I came with some
presumptions about what we were discussing. I certainly didn't mean
any hyperbole. Rather, I have one very specific thing in mind: in some
security contexts, it's important that certain data doesn't hit the
disk but rather remains in memory. Talk all you want about how this
shouldn't be a real requirement, but actually, in certain contexts it
very much is. Now, it might be the case that bash really isn't the
right tool for that kind of thing, and I shouldn't use bash for tasks
with security requirements as such. But I sort of love bash, and have
written a lot of it, and I want it to be suitable for this. So from my
perspective, we're not talking about a mere optimization, but instead
something that either makes herestrings available for usage in this
context, or keeps them unavailable in this context.
I hope that can shed light on the motivation a bit. Pass got hit by
this a bit ago:
https://git.zx2c4.com/password-store/commit/?id=367efa5846492e1b0898aad8a2c26ce94163ba24
Anyway, the more interesting thing is discussing what a proper fix
would be. Do you see anything conceptually wrong with the NONBLOCK
approach I suggested? In theory, would that work? Another thing I was
curious about is - what about internally treating "x <<y" as "echo y |
x"? Are these somehow not quite equivalent because x is in a subshell
in one but not the other, or something like that? And if that's so,
would my NONBLOCK suggestion incur similar issues?
Jason
- Re: "here strings" and tmpfiles, (continued)
- 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
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/11
- Re: "here strings" and tmpfiles, Daniel Kahn Gillmor, 2019/04/11
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/11
- Re: "here strings" and tmpfiles,
Jason A. Donenfeld <=
- Re: "here strings" and tmpfiles, Jason A. Donenfeld, 2019/04/11
- Re: "here strings" and tmpfiles, Jason A. Donenfeld, 2019/04/11
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/11
- Re: "here strings" and tmpfiles, Greg Wooledge, 2019/04/11
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/11
- Re: "here strings" and tmpfiles, Robert Elz, 2019/04/11
- Re: "here strings" and tmpfiles, Chet Ramey, 2019/04/11
- Re: "here strings" and tmpfiles, konsolebox, 2019/04/10
Re: "here strings" and tmpfiles, konsolebox, 2019/04/09