radius.log permissions issue

[John Dennis]

On 07/16/2009 08:12 AM, Philip Molter wrote:
>
> On Jul 16, 2009, at 4:03 AM, A.L.M.Buxey at lboro.ac.uk wrote:
>
>> Hi,
>>
>>> Is this a known bug? Is there a workaround other than creating the file
>>> by hand and setting its ownership before starting freeradius?
>>
>> ?? how are you starting this server - the file/directory should be
>> radiusd:radiusd
>> and when run it will do the 'correct thing'
>
> /usr/sbin/radiusd -d /etc/raddb as user root. As posted before, the
> config file has directives to switch to user radiusd and group radiusd
>
> The directory has the proper permissions, but the radius.log file
> doesn't exist. When the radiusd program starts up, it creates the
> radius.log file in the proper directory, but the file has 0640
> permissions owned by user root, group radiusd.

FWIW, in our RPM's we force the creation of the radius.log file with 
ownership radiusd:radiusd at installation time before the server even runs.

If you don't force the creation of the file with the right ownership 
then I think the issue revolves around when a log message is first 
emitted. The log file gets created the first time a log message is 
emitted. The server starts as root. During it's initialization phase it 
raises and lowers it's operating permissions between the root and 
radiusd user identity via the fr_suid_up() and fr_suid_down() calls. 
When it gets ready to process events it settles down to radiusd via 
fr_suid_down_permanent().

If the first log message occurs when the server is in a fr_suid_up() 
mode (e.g. running as root instead of as radiusd) then you'll get the 
behavior you've seen.

The code paths are way to complicated for static analysis to see if and 
when a log message might be emitted the server is in a high privilege 
mode. It does seem like it might happen if you start the server in debug 
mode because the server is much more verbose.

There are various strategies to assure the newly created log file has 
the right ownership:

* drop privileges prior to calling fopen()
* call chown() after fclose() at the exit of the logging call.
* pre-create the file if necessary very early during start up.

I think the latter is preferable as it avoid the expense of setting or 
checking for the right ownership for every log message emitted (ouch).

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/