I keep forgetting things. The other thing I wanted to bring up is that
I suspect bash's actual implementation of temporary files is
problematic and might have some of the classic /tmp and TOCTOU style
attacks. The current implementation is three-fold via ifdefs:
char *
sh_mktmpname (nameroot, flag
On Thu, Apr 11, 2019 at 6:02 AM Jason A. Donenfeld wrote:
> curious about is - what about internally treating "x <
Hi Chet,
On Wed, Apr 10, 2019 at 3:07 PM Chet Ramey 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
On Wed 2019-04-10 16:16:44 -0400, Chet Ramey wrote:
> Is it just that people have not realized all along that most shells,
> certainly all historical shells, that implement here documents use temp
> files to do it? It's really only the ash-based shells (not an insignificant
> portion of the shells
On Thu, Apr 11, 2019, 4:45 AM Chet Ramey wrote:
> On 4/10/19 4:33 PM, konsolebox wrote:
> > On Wed, Apr 10, 2019 at 11:15 PM Chet Ramey wrote:
> >> If we're going to go off into hypotheticals and speculation, it would be
> >> nice if memfd_create were available universally.
> >
> > I see many pa
On 4/10/19 4:33 PM, konsolebox wrote:
> On Wed, Apr 10, 2019 at 11:15 PM Chet Ramey wrote:
>> If we're going to go off into hypotheticals and speculation, it would be
>> nice if memfd_create were available universally.
>
> I see many parts in lib/* that adapts to available system features
> like
On 10/4/2019 09:04, Greg Wooledge wrote:
> On Wed, Apr 10, 2019 at 11:59:19AM -0400, Daniel Kahn Gillmor wrote:
>> If we look at the problem from the perspective of the risk of
>> herestring/heredoc content leaking to non-ephemeral storage,
>
> The content is already in the damned SHELL SCRIPT.
>
On Wed, Apr 10, 2019 at 11:15 PM Chet Ramey wrote:
> If we're going to go off into hypotheticals and speculation, it would be
> nice if memfd_create were available universally.
I see many parts in lib/* that adapts to available system features
like mmap and MAP_ANONYMOUS. I don't see why memfd_c
On Tue, Apr 9, 2019 at 10:01 PM Jason A. Donenfeld wrote:
> 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
On 4/10/19 11:59 AM, Daniel Kahn Gillmor wrote:
> On Wed 2019-04-10 09:07:27 -0400, Chet Ramey wrote:
> I think we all agree that avoiding the filesystem where possible is
> likely to be an optimization and improvement (it means the heredoc will
> work in some circumstances where it didn't work be
On Wed, Apr 10, 2019 at 11:59:19AM -0400, Daniel Kahn Gillmor wrote:
> If we look at the problem from the perspective of the risk of
> herestring/heredoc content leaking to non-ephemeral storage,
The content is already in the damned SHELL SCRIPT.
How much more "non-ephemeral" can it get?
On Wed 2019-04-10 09:07:27 -0400, Chet Ramey wrote:
> 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
On 4/9/19 12:19 AM, Robert Elz wrote:
> Date:Mon, 08 Apr 2019 17:04:41 -0700
> From:L A Walsh
> Message-ID: <5cabe199.9030...@tlinx.org>
>
> | On 4/8/2019 7:10 AM, Chet Ramey wrote:
>
> | > Pipes are objectively not the same as files. They
> | >
> | > 1. Do n
On 4/9/19 7:48 PM, L A Walsh wrote:
>
> I am aware of that, however, if a pipe implementation
> *stops* on reaching a full condition from some 'tmp-storage-space'
> and awaits for space to become available, a similar dynamic would
> apply. That's all.
Is there a pipe implementation ou
On Wed, Apr 10, 2019, 1:09 AM Eli Schwartz wrote:
> That being said, it seems like a rather odd place to configure and use a
> heavyweight shell merely to allow third parties to include
> downstream-specific bashisms. I think there is a great deal of wisdom in
> the fact that the referenced issue
On 4/10/19 3:44 AM, Matej Vargovčík wrote:
> Dear Sirs,
> I had a problem losing bash history when switching between terminals in
> tmux. I reported the issue in tmux, but the developers have told me that
> it's a bash problem and I should report it here. Please see this thread for
> more details:
On 4/9/19 10:07 AM, konsolebox wrote:
> Perhaps bash can also look at /dev/shm. It's a common tmpfs, but I
> haven't checked if it's standard and what utility mounts it. I don't
> really use it.
Another non-portable feature.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
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
On Wed, Apr 10, 2019 at 09:44:34AM +0200, Matej Vargovčík wrote:
> I had a problem losing bash history when switching between terminals in
> tmux. I reported the issue in tmux, but the developers have told me that
> it's a bash problem and I should report it here. Please see this thread for
> more
On 4/9/19 1:03 AM, pepa65 wrote:
> I think Linda's main drive is to seek improvement in how bash works. Now
> that lack of memory is in no way a constraint for the vast majority of
> situations where bash is commonly used, it would be great if that memory
> could be used instead of writing to a fi
Dear Sirs,
I had a problem losing bash history when switching between terminals in
tmux. I reported the issue in tmux, but the developers have told me that
it's a bash problem and I should report it here. Please see this thread for
more details:
https://github.com/tmux/tmux/issues/1671
Thank you fo
On Tue, Apr 09, 2019 at 04:48:30PM -0700, L A Walsh wrote:
> But the implementation of process substitution in bash
> isn't implemented that way in the currently released version. It
> uses a tmp file on a disk of fixed size to store *all* of the output
> of the 'writer' before the reader is c
On Tue, Apr 09, 2019 at 04:48:30PM -0700, L A Walsh wrote:
> > cp <(process) /tmp/foo
> ---
> *red face* I'd never tried to copy something that
> looked like input redirection. My apologies on my misconception.
One of the archetypal examples that we give when explaining process
substitut
23 matches
Mail list logo
