On 2020-09-01 04:26, Viktor Dukhovni wrote:
On Aug 31, 2020, at 10:57 PM, Jakob Bohm via openssl-users <openssl-users@xxxxxxxxxxx> wrote:
Given the practical imposibility of managing atomic changes to a single
POSIX file of variable-length data, it will often be more practical to
create a complete replacement file, then replace the filename with the
"mv -f" command or rename(3) function. This would obviously only work
if the directory remains accessible to the application, after it drops
privileges and/or enters a chroot jail, as will already be the case
for hashed certificate/crl directories.
There is no such "impossibility", indeed that's what the rename(2) system
call is for. It atomically replaces files. Note that mv(1) can hide
non-atomic copies across file-system boundaries and should be used with
care.
Note that rename(3) and link(2) do replace the file name, by making the
replaced name point to a new inode, thus it would not work with calls
thatmonitor an inode for content or statis change.
There is no basic series of I/O calls that completely replace file contents
inone step, in particular write(2) doesn't shorten the file if the new
contentsis smaller than the old contents.
And this is why I mentioned retaining an open directory handle, openat(2),
...
There's room here to design a robust process, if one is willing to impose
reasonable constraints on the external agents that orchestrate new cert
chains.
As for updating two files in a particular order, and reacting only to
changes in the one that's updated second, this behaves poorly when
updates are racing an application cold start. The single file approach,
by being more restrictive, is in fact more robust in ways that are not
easy to emulate with multiple files.
What exactly is that "cold start" race you are talking about?
Obviously, coding the logic to react badly to only one of two
files being present would not work with rules that one of those
two needs to arrive/change after the other.
If someone implements a robust design with multiple files, great. I for
one don't know of an in principle decent way to do that without various
races, other than somewhat kludgey retry loops in the application (or
library) when it finds a mismatch between the cert and the key.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
