Re: [Bug-gnu-radius] Are there good reasons for running radiusd as user 'root'?

[Maurice Makaay]

Hi,

> No, it doesn't. Radiusd intentionally does not keep log file descriptors
> open. There is a set of good reasons for that, the most important ones
> being: 1) to avoid keeping too many fds open so the system limit is
> not exceeded, 2) to simplify operation when the logfile is rotated
> and replaced by a fresh one (keeping file handle open would require
> closing and reopening it, which in turn would require some kind of
> notification procedure (probably a new signal) which would unnecesarly
> complicate the code and is clumsy from user point of view).

Being used to apache httpd this wouldn't be a big problem to me, but you're 
right if you say that this makes things easier in the end.
 
> The problem with logs in non-root startup mode is not a programming
> problem, so it cannot and should not be solved by radiusd itself. The
> right way to solve it is for the user to create a separate logging
> subirectory, say /var/log/radiusd, make it owned by the uid that
> radiusd runs under, and set right priviledges to it.

This is not completely true. Radiusd calls radlog before dropping privileges
(because the uid to run as is set in the config file and the privileges are
dropped only after reading the configuration). So at startup, there could be
some logfiles created by radiusd which are owned by the root user. After 
dropping privileges radiusd can't write to them anymore.

Two possible solutions would be:

- Having radiusd chown all channel logfiles to the run-user before dropping
  the privileges;

- Setting the uid to run as as a startup flag, so dropping priviliges can be
  done before doing anything else.

I would prefer the first option, because I think the user should be able to
set the uid from the config file. Setting it from the startup flags would
in my opinion only be an extra.


Regards,

-- Maurice Makaay