[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Avoiding file-based constraints for tmp files (ws Re: [minor] umask 400
From: |
L A Walsh |
Subject: |
Avoiding file-based constraints for tmp files (ws Re: [minor] umask 400 causes here-{doc,string} failure) |
Date: |
Mon, 12 Mar 2018 13:05:05 -0700 |
User-agent: |
Thunderbird |
Stephane Chazelas wrote:
$ bash -c 'umask 400; cat <<< test'
bash: cannot create temp file for here-document: Permission denied
...
I can think of several ways to address it:
---
Another way to address it (with env-based limits for instance + sum):
If using less than env-mem limits for here-docs, then
create the here-doc in memory.
Have '<' read from a file-position pointer in the memory buffer.
- Would allow "seeking" if that's an issue.
- for _many_ here-docs, size is relatively small -- so would preclude many
small file IO ops for small here-docs. This may be more important for
here-docs below the media's sector size (w/4K sectors: more common),
or on a
RAID, less than strip size.
- a basic file-w/sequential read facility is not difficult to write;
- no security issues or race-windows of a file temporarily on disk
- no name collisions or lookups
For small systems, even allowing 8-64K in memory could help many usages
w/small
H-docs, but on systems w/many GigaBytes of memory -- all H-doc usage could
come from memory.
In cases where the heredoc had to be accessible from multiple processes,
could use shared-memory if available.
In all cases, fall-back could be to current solution(s).
As a comparison, 'vim' would use temp files to handle large-file editing.
With shift to systems having more memory -- most files can be fully
edited in
memory.
Right now, my linux system has 5.3G available in tmp, compared to 149G
available in free memory.
What would be the downside(s) of such an implementation?