>>>>> Phil Pennock <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
