[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