Freeradius 3.0.21 with chroot enables fails to start from the Systemd unit file.

[Antonios Kalkakos]

On 18/04/2022 16:24, Alan DeKok wrote:
> On Apr 18, 2022, at 6:53 AM, Antonios Kalkakos <akalkakos at hotmail.com> wrote:
>> I am trying to test chroot on a Raspberry Pi running the distro-provided Freeradius 3.0.21 on the 32bit Raspberry Pi OS (Debian) 11.
> 
>    Chroot should work by itself.  I doubt that it will work with systemd, though.
> 
> ...
>> Apr 16 14:14:37 raspberry systemd[1]: freeradius.service: Main process exited, code=exited, status=1/FAILURE
> 
>    Hmm... "FAILURE".   Maybe there's an additional error message buried somewhere inside of the systemd logs?
Nothing is logged in /var/log/freeradius; logs in /var/log/syslog don't 
give any detail:

-------------------syslog----------------------------------
Apr 18 17:00:53 raspberry systemd[1]: Starting FreeRADIUS multi-protocol 
policy server...
Apr 18 17:00:54 raspberry freeradius[6975]: FreeRADIUS Version 3.0.21
Apr 18 17:00:54 raspberry freeradius[6975]: Copyright (C) 1999-2019 The 
FreeRADIUS server project and contributors
Apr 18 17:00:54 raspberry freeradius[6975]: There is NO warranty; not 
even for MERCHANTABILITY or FITNESS FOR A
Apr 18 17:00:54 raspberry freeradius[6975]: PARTICULAR PURPOSE
Apr 18 17:00:54 raspberry freeradius[6975]: You may redistribute copies 
of FreeRADIUS under the terms of the
Apr 18 17:00:54 raspberry freeradius[6975]: GNU General Public License
Apr 18 17:00:54 raspberry freeradius[6975]: For more information about 
these matters, see the file named COPYRIGHT
Apr 18 17:00:54 raspberry freeradius[6975]: Starting - reading 
configuration files ...
Apr 18 17:00:54 raspberry freeradius[6975]: Debug state unknown 
(cap_sys_ptrace capability not set)
Apr 18 17:00:54 raspberry freeradius[6975]: Creating attribute Unix-Group
Apr 18 17:00:54 raspberry freeradius[6975]: rlm_cache (cache_eap): 
Driver rlm_cache_rbtree (module rlm_cache_rbtree) loaded and linked
Apr 18 17:00:54 raspberry freeradius[6975]: tls: Using cached TLS 
configuration from previous invocation
Apr 18 17:00:54 raspberry freeradius[6975]: tls: Using cached TLS 
configuration from previous invocation
Apr 18 17:00:54 raspberry freeradius[6975]: rlm_detail (auth_log): 
'User-Password' suppressed, will not appear in detail output
Apr 18 17:00:54 raspberry freeradius[6975]: rlm_mschap (mschap): using 
internal authentication
Apr 18 17:00:54 raspberry freeradius[6975]: Ignoring "sql" (see 
raddb/mods-available/README.rst)
Apr 18 17:00:54 raspberry freeradius[6975]:  # Skipping contents of 'if' 
as it is always 'false' -- 
/etc/freeradius/3.0/sites-enabled/inner-tunnel:340
Apr 18 17:00:54 raspberry freeradius[6975]: radiusd: #### Skipping IP 
addresses and Ports ####
Apr 18 17:00:54 raspberry freeradius[6975]: Configuration appears to be OK
Apr 18 17:00:55 raspberry systemd[1]: freeradius.service: Main process 
exited, code=exited, status=1/FAILURE
Apr 18 17:00:55 raspberry systemd[1]: freeradius.service: Failed with 
result 'exit-code'.
Apr 18 17:00:55 raspberry systemd[1]: Failed to start FreeRADIUS 
multi-protocol policy server.
Apr 18 17:00:55 raspberry systemd[1]: freeradius.service: Consumed 
1.323s CPU time.
-------------------end of syslog----------------------------------

> 
>> Although I am not a Systemd or a Freeradius guru, I made a simple investigation with the following results:
> 
>    That's all a very good approach.
> 
>> b) As 'freerad' *with chroot enabled*, freeradius -f -lstdout returns immediately without reporting or logging any error(s):
>>
>> ----------freeradius -f -lstdout output---------------------
>> freerad at raspberry:$ freeradius -f -lstdout
>> Sat Apr 16 14:24:50 2022 : Info: Starting - reading configuration files ...
>> freerad at raspberry:$
>> ----------End of freeradius -f -lstdout output--------------
> 
>    If you do "echo $?" immediately after that, you'll see if the server exited with an error.
Yes, it just returns 1.
> 
>    I'd say try 3.0.25, maybe it produces better error messages.
> 
Will give a try on a testing machine on my spare time. It's a (sometimes 
unfortunate) requirement for me to work with the distro - provided 
packages.

>> Is this a permission problem or am I doing something wrong?
> 
>    chroot should work, but I can't recall trying it in the last few years.
> 
>    I doubt very much that chroot will work with systemd.  Systemd is just too weird, and has many additional requirements over a normal chroot process.
I totally agree with you! systemd sometimes makes simple things complicated.
> 
>    Alan DeKok.
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Antonios