Hi! For whatever reason "raddebug" doesn't work on our new radius servers. On the old ones I could simply run "raddebug" or "raddebug -t 0" to capture the current debug logs. On the new one it shows nothing. It simply runs without any output. Running freeradius-3.2.3-1.el9.x86_64 on AlmaLinux 9. All the prerequisites mentioned in the raddebug(8) are met: * radmin is in the path. * I start raddebug as root thus permissions shouldn't matter. * control socket is configured in mode rw and is accessible. * It creates a file like "/var/log/radius/radmin.debug.101128" which remains empty as well. * I don't run multiple raddebug processes. So I don't understand why it's not working... Regards, Gerald
On Aug 9, 2023, at 11:11 AM, Gerald Vogt <vogt@spamcop.net> wrote:
For whatever reason "raddebug" doesn't work on our new radius servers. On the old ones I could simply run "raddebug" or "raddebug -t 0" to capture the current debug logs.
On the new one it shows nothing. It simply runs without any output.
Running freeradius-3.2.3-1.el9.x86_64 on AlmaLinux 9.
All the prerequisites mentioned in the raddebug(8) are met: * radmin is in the path. * I start raddebug as root thus permissions shouldn't matter. * control socket is configured in mode rw and is accessible. * It creates a file like "/var/log/radius/radmin.debug.101128" which remains empty as well. * I don't run multiple raddebug processes.
So I don't understand why it's not working...
If I had to guess, it would be some kind of SELinux thing, or other "security" permissions thing. Alan DeKok.
On 10.08.23 13:32, Alan DeKok wrote:
On Aug 9, 2023, at 11:11 AM, Gerald Vogt <vogt@spamcop.net> wrote:
For whatever reason "raddebug" doesn't work on our new radius servers. On the old ones I could simply run "raddebug" or "raddebug -t 0" to capture the current debug logs.
On the new one it shows nothing. It simply runs without any output.
Running freeradius-3.2.3-1.el9.x86_64 on AlmaLinux 9.
All the prerequisites mentioned in the raddebug(8) are met: * radmin is in the path. * I start raddebug as root thus permissions shouldn't matter. * control socket is configured in mode rw and is accessible. * It creates a file like "/var/log/radius/radmin.debug.101128" which remains empty as well. * I don't run multiple raddebug processes.
So I don't understand why it's not working...
If I had to guess, it would be some kind of SELinux thing, or other "security" permissions thing.
It's not SeLinux. There are no denials and I have double-checked in permissive mode. It seems the problem is when I start raddebug as root. It creates the radmin.debug log file as root: -rw-rw-r--. 1 root root 0 Aug 10 22:06 /var/log/radius/radmin.debug.30393 and radiusd cannot write into that. If I run # sudo -u radiusd raddebug it'll work. That wasn't necessary on EL7. I thought radiusd would create the debug log file. If it's raddebug (or radmin) I guess it should make sure that it's using the correct user/group. Or is there a new configuration option to set the user/group for the debug log file? -Gerald
Looking at the raddebug shell script, the issue is that it wants to read the security.group configuration: group=`$radmin -e "debug file radmin.debug.$$" -e "show config security.group"` But that is empty: # user = radius # group = radius because it's using the user and group set in the radiusd.service unit... So technically, radmin should be able to determine the group name which the server is actually using instead of relying on static configuration. Regards, Gerald On 10.08.23 22:10, Gerald Vogt wrote:
On 10.08.23 13:32, Alan DeKok wrote:
On Aug 9, 2023, at 11:11 AM, Gerald Vogt <vogt@spamcop.net> wrote:
For whatever reason "raddebug" doesn't work on our new radius servers. On the old ones I could simply run "raddebug" or "raddebug -t 0" to capture the current debug logs.
On the new one it shows nothing. It simply runs without any output.
Running freeradius-3.2.3-1.el9.x86_64 on AlmaLinux 9.
All the prerequisites mentioned in the raddebug(8) are met: * radmin is in the path. * I start raddebug as root thus permissions shouldn't matter. * control socket is configured in mode rw and is accessible. * It creates a file like "/var/log/radius/radmin.debug.101128" which remains empty as well. * I don't run multiple raddebug processes.
So I don't understand why it's not working...
If I had to guess, it would be some kind of SELinux thing, or other "security" permissions thing.
It's not SeLinux. There are no denials and I have double-checked in permissive mode.
It seems the problem is when I start raddebug as root. It creates the radmin.debug log file as root:
-rw-rw-r--. 1 root root 0 Aug 10 22:06 /var/log/radius/radmin.debug.30393
and radiusd cannot write into that.
If I run
# sudo -u radiusd raddebug
it'll work.
That wasn't necessary on EL7. I thought radiusd would create the debug log file. If it's raddebug (or radmin) I guess it should make sure that it's using the correct user/group. Or is there a new configuration option to set the user/group for the debug log file?
-Gerald
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Aug 15, 2023, at 8:22 AM, Gerald Vogt <vogt@spamcop.net> wrote:
Looking at the raddebug shell script, the issue is that it wants to read the security.group configuration:
group=`$radmin -e "debug file radmin.debug.$$" -e "show config security.group"`
But that is empty:
# user = radius # group = radius
because it's using the user and group set in the radiusd.service unit...
So technically, radmin should be able to determine the group name which the server is actually using instead of relying on static configuration.
How? Patches are welcome. Just to note: * there may be more than one server running on the same system * the user running raddebug may not have permission to read the configuration files Or, just uncomment the "user" and "group" configuration. And set them to the correct names for the user/group. This won't cause problems. The server will check that it's already running as that user, and will skip any calls to setuid(). And then raddebug will work correctly. Alan DeKok.
participants (2)
-
Alan DeKok -
Gerald Vogt