On 9/16/12 4:40 PM, Roland Mainz wrote:
> Hi!>> ---->> While looking at the issues around temporary files I noticed
> that some> shell scripts create a lot of temporary files...> ... which leads
> to the question: Wouldn't it be better to create one> temporary directory
> with a random name and then create all temporary> files in that directory ?>>
> AFAIK the advantages are:> - This should be faster in cases that /tmp is
> clogged with thousands> of files. I've seen that in some caases /tmp on
> Solaris can have> 50000+ actively used files (not all from ksh93) ... which
> borders IMO> near insanity to handle that (usual suggestion is to set TMPDIR
> to> something like */tmp/*$LOGNAME/ in /etc/profile). This assume we open>
> the directory using |openat()| to avoid that the shell always needs to> do a
> full path lookup starting from ${TMPDIR}.> - The files in the temporary
> directory can be picked in a more> descriptive fashion, e.g. made out of>
> "l<lineno>n<namespace>f<functionname>s<subshelllevel>p<pid>c<counter>t<timestamp>.tmp">
> (namespace, functionname and subshelllevel are only used if> appiliable/used
> and "counter" is an |uint64_t| which is increased for> each temporary file.
> The <pid> part names sure this is unique even if> a subshell called |fork()|
> and then fork'ed child processes) or> something like that.>> Disadvatages:> -
> It's harder to delete the directory> - At least one extra syscall is required
> (|mkdir()|)> - More code, making ksh93 bigger>> ---->> Bye,> Roland
For what it's worth, Mac OS X (Leopard and above) sets TMPDIR to a path name
similar to:
*/private/var/folders/CV/CVDQMSVEFEOallifs59+wE+++TI/*-Tmp-
I did a quick-and-dirty check of ksh Version AJM 93u+ 2012-06-12 as follows:
% echo $(yes) >&-
# From another window:
% lsof -a -c ksh +c 0 -u terry
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
...
ksh 1288 terry 1u REG 14,16 61865984 32418
*/private/var/folders/CV/CVDQMSVEFEOallifs59+wE+++TI/*-Tmp-/sf06.cis
...
So, ksh is apparently using TMPDIR when it generates temporary files.
Apple offers no documentation for this /feature/. About the only useful
information I've been able to find is this excerpt from dhaveconfig's reply
post in http://arstechnica.com/civis/viewtopic.php?f=19&t=42677:
quote:
Originally posted by Stern:
quote:
Originally posted by Hal Itosis:
I guess that */var/folders/zz/** hierarchy is the temp area for the
root "user", whereas the initial (uid 501) user gets
*/var/folders/zz/Ap/**
Nope, on this machine I'm UID 501 and the path is
*/var/folders/eg/egv70P+FGRqJ7U5g85yPcU+++TI/*.
Some snippets from a different discussion on this topic (not from here,
quoting so it's clearer I didn't write these bits, but not willing to out
the authors entirely.)
quote:
The plus and the minus signs are merely a manifestation of the
encoding scheme, which starts with a concatenation of the UUID and the
big-endian version of the uid and remaps the resultant
bytes to ASCII characters from the string "+-012...ABC...abc...xyz". The
remapping logic is simple and rather uninteresting.
quote:
the two characters "zz", which are the first two characters of the
aforementioned encoding, represent a "bucket"--partitioning of the
namespace so that too many users don't end up in a single directory. The
programmed bucket length is 2, hence 2 characters.
quote:
As for why, I remember hearing something about security from Apple...
this "randomization" along with the fact that this is done
through a trusted intermediary (launchd) is meant to help thwart
attacks that can race-exploit a known, shared /tmp by creating files
that another process is looking for. Something along those lines...
Unless I'm missing something, they probably didn't think this
through. The permissions on the per-user directories prohibit
access to another user, but as you said, I'm not sure either why the
randomization is **needed**. After all, as an attacker, if necessary I
could implement the (currently deterministic) encoding myself.
Terrence Doyle
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
