exfile / file locking

[Phil Mayers]

Context: we have quite an involved config that was built on 2.x, and we 
used to make use of the sql_log module, with a locally-constructed 
external process which follows the file and relays to our SQL service. 
That external process has a very carefully constructed open/lock/rename 
scheme designed to cooperate with how 2.x worked.

That module has gone away on 3.x and we've been using an instance of sql 
with the null driver and "logfile" option set, which I was under the 
impression used the same locking scheme.

We don't use the detail writer/reader construction because we're using 
this in the "postauth" section, for logging of auths on devices which 
don't do useful accounting (layer2 switches doing mac-based VLANs).


Having finally got round to serious porting to 3.x, we're seeing 
corruption of this file on 3.0.15 and I am suspicious of the exfile 
locking functions which I see are now being used for this. Specifically:

https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/main/exfile.c#L332

...seems to perform an fstat/re-open-if-unlinked check, but this happens 
*after* any fcntl locking has been done, and there's no attempt to 
re-lock the file on this re-open. So, if this codepath gets triggered, 
the file is now held and written to without locking, when it should be 
locked. Bug?

More generally, I've re-read the exfile code a couple of times and I am 
suspicious of the basic construction. What performance problem is the 
open/dup caching setup intended to solve? Put another way, why not 
open/close the file using the traditional posix APIs on each run?

Regards,
Phil