rlm_detail and radrelay concurrence

[Nicolas Baradakis]

Michael Chernyakhovsky wrote:

> i use radrelay
> there are errors in log from rlm_detail like
> Error: rlm_detail: Couldn't open file /var/log/radius/radacct/detail-relay: Bad file descriptor
> 
> [...]
> 
> Bad file description error appear because radrelay
> can remove detail file while rad_detail trying to aquire filelock, I
> think (line 655 of radrelay.c).

I don't think so: you can continue to write in a file which has been
unlinked.

> so detail_move can be called by radrelay while rad_detail already
> opens detail (line 201) have outfd and try to aquire lock. after radrelay
> made rad_unlockfd(fileno(fp), 0) (line 670), rlm_detail try to fdopen (line
> 243) and will get error.

Indeed, things are done in the wrong order. This was already discussed
on the freeradius-devel mailing list. The thread starts here:
http://lists.freeradius.org/pipermail/freeradius-devel/2005-March/008139.html

I think the fixes are in CVS head but they were never included in any
stable release.

> btw, why to sleep 1000ms on 665 at radrelay.c?
> how rlm_detail can write something to detail.work, while file is locked
> by radreplay?

rlm_detail opens the file and wait for the lock. During this time,
the file may be renamed by radrelay, but rlm_detail doesn't notice it.
Therefore the file descriptor in rlm_detail points to detail.work.

-- 
Nicolas Baradakis