>> How does fexecve() make anything possible here that wasn't possible
>> before? It seems to me that updating .so libraries has always
>> carried this risk, so I must be missing something.
> Without fexecve() it's at least theoretically possible to remove the
> old bins first, update the libraries, and install new bins, so that
> the old bins are gone and can't be exec'd when the new libraries
> appear.
Hmm, good point.
But, even with fexecve() it's possible to destroy the old bins before
removing them (truncate to zero size is perhaps the simplest way), so
descriptors onto them, if any, no longer point to executable content.
Admittedly, that requires at least a tiny update to installation
procedures.
It's also theoretically racy, in that you could have
process A other process(es)
fexecve() file
page in executable
prepare to load libs
destroy file
unlink file
replace libs
start loading libs
but that race is (a) highly unlikely and (b) equally possible with
plain execve(). (In my experience, a paged-in executable continues to
work as long as it stays paged in even if its backing file is
destroyed; perhaps that's changed in -current.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML [email protected]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
