>>>>> Phil Pennock <pdp@???> writes:
>>>>> On 2012-01-15 at 20:23 +0700, Ivan Shmakov wrote:
[…]
>> # rm -f new-params
>> # touch new-params
>> # chown exim:exim new-params
>> # chmod 0400 new-params
>> # certtool --generate-privkey --bits 512 >new-params
>> # echo "" >>new-params
>> # certtool --generate-dh-params --bits 1024 >> new-params
>> # mv new-params gnutls-params
>> --cut: http://exim.org/exim-html-current/doc/html/spec_html/ch39.html --
>> Arguably, it doesn't make sense to use >> here. Also, while it
> Yes it does. The first invocation of certtool will truncate, the
> echo and second invocation append. The logic is correct.
I contest the style, not the logic. The code above open(2)'s
the same file thrice, while it could easily open it only once.
[…]
>> Consider, e. g., the following example code instead:
>> #!/bin/sh
>> rm -f new-params
>> umask 0277
>> {
>> certtool --generate-privkey --bits 512
>> echo ""
>> certtool --generate-dh-params --bits 1024
>> } > new-params
>> chown exim:exim new-params
>> mv new-params gnutls-params
> Looks good, although my recollection is that in some older shell on
> some systems (which Exim runs on), braces for command-pipelines don't
> redirect well and you'd need to use parentheses and a sub-shell.
Agreed.
(Also, exec > new-params may be used here instead, though for
safety, it'd be necessary to redirect stdout elsewhere after the
final certtool(1) invocation, which seems overly verbose.)
>> Should something like mktemp(1) be used as well, the rm(1)
>> vs. touch(1) race will also be avoided, and it will be perfectly
>> safe to run multiple instances of the code above at once. (Just as
>> with Exim computing new D-H parameters by itself.)
> The rm vs touch race is non-existent, because this is not happening
> in /tmp, but in the Exim spool directory which is only writeable by
> the Exim run-time user (and root). The target file is replaced
> atomically. Any process which can interfere with the file creation
> can already do anything at all that the Exim processes can do.
The issue is that there may be several simultaneously-running
instances of the code above. These may open the same new-file
and write to it simultaneously. (Though the chances are that
one wouldn't ever experience such a behavior in practice.)
> The hoops to be jumped through for /tmp and its like are not needed
> in this case.
The primary reason behind mktemp(1) is that it allows for safe
(O_CREAT | O_EXCL) file creation in Shell, which is seemingly
impossible by any other (conventional) means.
> I'm unconvinced that anything here needs to change.
--
FSF associate member #7257
