Subject: Re: nncp-exec -use-tmp path

From: Sergey Matveev <[email-masked]>
Date: Sat, 16 Jan 2021 00:18:10 +0300

Greetings!

*** John Goerzen [2021-01-15 14:42]:
>Anyhow, poking around in the code, I think that's due to to the call to
>ioutil.TempFile in src/tx.go instead of using NewTmpFile (defined in tmp.go).

Well, documentation for nncp-exec does not tell about temporary file
nothing -- that is bad, will fix it hopefully on that weekends However
the code for *that* temporary file is the same as for "nncp-file -",
which has more description about the behaviour: http://www.nncpgo.org/nncp_002dfile.html

ioutil.TempFile is a right call in that case: it creates temporary file
in TMPDIR: https://golang.org/pkg/os/#TempDir -- so you can control its
placement with TMPDIR environment variable. That temporary file has
narrow permissions and moreover it is delete immediately after creation
-- to delete it anyway after process is finished/crashed/killer/whatever.

It should not be the spool directory by default. For example one of my
spool directories located on a ZFS dataset with quota=2G and if
temporary file will be in the spool, then I can not transfer more than
1G of data, because contents of that temporary file must be copied in
the spool. But, anyway you can control its placement with $TMPDIR.

NewTmpFile differs from ioutil.TempFile only in one thing: it creates
files (and tmp/ directory) with umask-friendly 0666 (0777 for tmp/)
permissions. And NewTmpFile is aimed to be used only for really created
encrypted packets -- it is renamed after successful writing. And it has
to be in the spool, because renaming won't work if source and
destination files are on different filesystems.

So ioutil.TempFile is really for temporary files that will be deleted
after usage and nncp-file/nncp-exec are the only use cases for it.
NewTmpFile is for file that is for preparing encrypted packet:
it has to be in spool (actually noone guarantees that spool/tmp and
spool/NODE/{rx,tx} are on the same filesystem, but user will quickly
find that everything does not work :-)) and it has to be umask friendly.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF