The commit 0436af5abd8b73e breaks startup for jsonrpcs module.
Logs: ``` Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_sock.c:358]: jsonrpc_dgram_init_server(): failed to change the owner/group for /var/run/kamailio/kamailio_rpc.sock to 33.0;Operation not permitted[1] Jul 5 10:04:41 kam01 kamailio[4951]: CRITICAL: jsonrpcs [jsonrpcs_sock.c:423]: jsonrpc_dgram_init_socks(): initializing datagram server function returned error Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_sock.c:246]: jsonrpc_dgram_mod_init(): init datagram sockets function failed Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_mod.c:1150]: mod_init(): cannot initialize datagram transport Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: <core> [core/sr_module.c:849]: init_mod(): Error while initializing module jsonrpcs (/usr/lib/x86_64-linux-gnu/kamailio/modules/jsonrpcs.so) ```
Relevant cfg: ``` loadmodule "jsonrpcs.so" modparam("jsonrpcs", "pretty_format", 1) modparam("jsonrpcs", "dgram_user", "www-data") modparam("jsonrpcs", "dgram_group", "root") modparam("jsonrpcs", "transport", 7) ```
Previously Kamailio was started as root, and then configured with -u $USER and -g $GROUP to drop privileges to the lower user/group. During startup Kamailio could create the socket with the correct permissions. The mentioned commit changes this to: start Kamailio directly as user Kamailio and group Kamailio, which don't have privileges create the sockets with the correct permissions.
Not sure about the motivation about this change, so I don't want to simple revert it. Maybe @sergey-safarov or other developers can comment.
Is it reproducible on clean installation? Or only after upgrade?
Is issue fixed after server reboot?
all files under `/var/run/` (a symbolic link to `/run`) must be created from scratch on server reboot. Could you make a test: 1) systemctl disable kamailio 2) reboot 3) ls -ld /var/run/kamailio 4) ls -l /var/run/kamailio 5) systemctl enable --now kamailio 6) ls -ld /var/run/kamailio 7) ls -l /var/run/kamailio
And paste here output of these commands.
Is it reproducible on clean installation? Or only after upgrade?
Is issue fixed after server reboot?
Thanks Sergey. I did a server reboot, did not changes anything. Will now try the other steps.
all files under `/var/run/` (a symbolic link to `/run`) must be created from scratch on server reboot. Could you make a test:
1. systemctl disable kamailio 2. reboot 3. ls -ld /var/run/kamailio 4. ls -l /var/run/kamailio 5. systemctl enable --now kamailio 6. ls -ld /var/run/kamailio 7. ls -l /var/run/kamailioAnd paste here output of these commands.
This is without the problematic cfg parameter:
root@kam01:/home/henning# systemctl disable kamailio Synchronizing state of kamailio.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable kamailio Removed /etc/systemd/system/multi-user.target.wants/kamailio.service. reboot
root@kam01:/home/henning# ls -ld /var/run/kamailio ls: cannot access '/var/run/kamailio': No such file or directory
root@kam01:/home/henning# ls -l /var/run/kamailio ls: cannot access '/var/run/kamailio': No such file or directory
root@kam01:/home/henning# systemctl enable --now kamailio Synchronizing state of kamailio.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable kamailio Created symlink /etc/systemd/system/multi-user.target.wants/kamailio.service → /lib/systemd/system/kamailio.service.
root@kam01:/home/henning# ls -ld /var/run/kamailio drwxr-x--- 2 kamailio kamailio 120 Jul 5 10:46 /var/run/kamailio
root@kam01:/home/henning# ls -l /var/run/kamailio total 4 srw------- 1 kamailio kamailio 0 Jul 5 10:46 kamailio_ctl -rw-r--r-- 1 kamailio kamailio 5 Jul 5 10:46 kamailio.pid prw-rw---- 1 kamailio kamailio 0 Jul 5 10:46 kamailio_rpc.fifo srw-rw---- 1 kamailio kamailio 0 Jul 5 10:46 kamailio_rpc.sock
``` root@kam01:/home/henning# ls -ld /var/run/kamailio ls: cannot access '/var/run/kamailio': No such file or directory
root@kam01:/home/henning# ls -l /var/run/kamailio ls: cannot access '/var/run/kamailio': No such file or directory ```
Looks as not exist tmpfiles configuration file. I will make review of such file packaging.
About config options ``` modparam("jsonrpcs", "dgram_user", "www-data") modparam("jsonrpcs", "dgram_group", "root") ``` As now the `kamailio` main process started as a regular user, then the process does not have the capability to change process user and group. Extra capabilities may be added process back. Additional info https://manpages.debian.org/unstable/manpages/capabilities.7.en.html
Why you want to create Unix socket with owner other than default? Are you manage Kamailio via web server like `nginx`, `apache`?
Also, you can create drop-in and start Kamailio with required user and group ``` [Service] User=www-data Group=root ```
Or you can create drop-in and start Kamailio as before under root user and then drop process permission
On systemd, to change username or group please create drop-in
/etc/systemd/system/kamailio.service.d/10-user_group.conf file, like ``` [Service] User=root Group=root ExecStart= ExecStart=/usr/sbin/kamailio -P /run/kamailio/kamailio.pid -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY -u kamailio -g kamailio ``` Blank "ExecStart=" to clean `ExecStart` from the main `kamailio.service` unit file.
Hi Sergey, the reason to use this parameter is to enable SIREMIS Web GUI to communicate with Kamailio, as you guessed already. To start Kamailio as user www-data is probably not optimal from a security point of view.
If we provide this capabiltiy in the module, it should work in our packages as well. Do you remember why we changed this ExecStart in commit 0436af5?
If we provide this capability in the module, it should work in our packages as well.
If you want to add these extra capabilities via `SIREMIS` package, then yes. That will works. Required create drop-in like `/etc/systemd/system/kamailio.service.d/20-siremis.conf`.
This change made to fix the issue https://github.com/kamailio/kamailio/issues/2334.
From my point of view, the correct approach "starts daemons with the specified user and group".
If in some cases this is not enough, then extend capabilities via drop-in.
About creation of `/var/run/kamailio` need place `/usr/lib/tmpfiles.d/kamailio.conf` with following content. ``` D /run/kamailio 0700 kamailio kamailio - ``` And after deb package is installed, need to execute a script command like. ``` systemd-tmpfiles --create kamailio.conf >/dev/null 2>&1 ``` Victor Seva @linuxmaniac could you look suggestion above.
About extra capabilities via systemd unit file I will make some test.
@henningw please create file `/etc/systemd/system/kamailio.service.d/20-siremis.conf` with content ``` [Service] AmbientCapabilities=CAP_CHOWN ``` and then execute commands ```sh systemctl daemon-reload systemctl restart kamailio systemctl status kamailio ```
@henningw please create file `/etc/systemd/system/kamailio.service.d/20-siremis.conf` with content
[Service] AmbientCapabilities=CAP_CHOWNand then execute commands
systemctl daemon-reload systemctl restart kamailio systemctl status kamailio
Thanks, this worked great:
root@kam01:/home/henning# ls -la /var/run/kamailio/kamailio_rpc.sock srw-rw---- 1 www-data root 0 Jul 7 09:28 /var/run/kamailio/kamailio_rpc.sock
@linuxmaniac - make it sense to add it to debian packaging? Otherwise I can just document it in the jsonrpcs README.
Do we have more modules with the same behavior?
I just did a quick grep, it seems this is the only one.
make it sense to add it to debian packaging?
As it does not need in most cases, I think best options a package `/etc/systemd/system/kamailio.service.d/20-siremis.conf` for other packages then `kamailio`. This may be `kamailio-cfg-siremis` or `siremis` itself.
Is anything left to be addressed on this issue?
I think it should be documented in the jsonrpcs module, as packaging is probably a bit too much for this special case.
If I understood right, it is about kamailio being able to do chown internally. At least `ctl` module needs this capability as well. Probably connecting with kamcmd or kamcli face same problem if they are configured to run under different user/group, like it happens with apache2 (running siremis).
As the chown is inside kamailio code, my opinion is that this systemd option should be included in kamailio unit.
The ctl and jsonrpc modules are loaded in default config file, so changing its parameters should be as smooth as possible with default systemd unit. We practically keep the same capabilities as it used to be with init.d.
I can add the required permissions to `systemd` unit file.
@sergey-safarov, @linuxmaniac could you add the necessary file from comment https://github.com/kamailio/kamailio/issues/2391#issuecomment-654726464 to debian and rpm packaging?
File can be added, need to define which package. If file will be added into `kamailio` package, then it will affect all installation.
We can defined cfg packages like ``` kamailio-cfg-siremis ``` When you install siremis, then install specific cfg package.
The file can be added, need to define which package. If a file will be added into `kamailio` package, then it will affect all installation.
We can define cfg packages like
kamailio-cfg-siremisWhen you install siremis, then need to install a specific cfg package.
Hi Sergey, this is needed for jsonrpcs and ctl module and generally unrelated to SIREMIS. Both modules are in the default cfg. So it should be probably added to the main kamailio unit. See also comment from Daniel above.
then we can add this string into [`kamailio.service`](https://github.com/kamailio/kamailio/blob/master/pkg/kamailio/obs/kamailio.s...) ``` AmbientCapabilities=CAP_CHOWN ``` That will be more simple.
Ok, this sounds indeed easy, I will do it then. :-)
It should be fixed with referenced commit from above. Lets wait a bit for packaging tests and then i will backport as well.
Backports seems to be done.
Closed #2391.
-
Daniel-Constantin Mierla -
Henning Westerholt
-
sergey-safarov
-
Victor Seva