[sr-dev] Permission problem and setuid in Kamailio 1.5

Andrei Pelinescu-Onciul andrei at iptel.org
Tue Oct 13 12:08:13 CEST 2009


On Oct 13, 2009 at 12:55, marius zbihlei <marius.zbihlei at 1and1.ro> wrote:
> Hi all,
> 
> There is a permission problem if the daemon is started given -u and -g 
> parameters (sets up user and group for the process).
> 
> The do_suid function (defined in demonize.c) is called after the call to 
> init_modules(), so the mod_init functions of the configured module are 
> loaded before the call to do_suid. This wasn't a problem in 1.3 because 
> no module(I am aware off) use the uid and gid of the process to do 
> permission checks.
> 
> This has changed in 1.5, module carrierroute, as there is a check to see 
> if the route file in config-file mode (usually 
> /etc/kamailio/carrierroute.conf) has the right permission set on it 
> (Issues an warning if it's worldly writable and error if it's not 
> writable by the process owner). This of course is a problem because 
> kamailio hasn't yet setuid()/setgid() so the checks are done using the 
> wrong uid.

You should do the check then from child_init(PROC_INIT)
(rank==PROC_INIT). It's executed after setuid(), but before any real
forking (so you could still exit gracefully).


> 
> A correct (imho) course of action is to move the call to do_suid 
> function before the call to init_modules()(and before any other calls to 
> initialization functions).

No, the do_suid() is on purpose _after_ the mod_init() to allow the
modules to open sockets/files a.s.o. before the suid part
(e.g. this way if started as root a module can open a socket on a port <
1024 from mod_init).
All the operations that require special privileges should be done from
mod_init().

> 
> I've attached a small patch that does this (tested).
> 
> There are any considerations on why the init_modules() should be called 
> with another uid/gid?

Yes, see above.

Note that the PROC_INIT stuff will work on sip-router and probably not
on old kamailio (> 3.0). You could try using 0 there (PROC_MAIN), but it
will be called after forking some of the processes (the exit won't be as
graceful).


Andrei



More information about the sr-dev mailing list