[sr-dev] some observations on kamailio

[Daniel Pocock]

- suid code: I notice that the daemon drops perms before loading the TLS
private key file.  It would be better to load the file first, so that
only root needs read access to the private key - does the current TLS
module architecture support that?

- comments on 1024 bit RSA: the docs recommend not to use key sizes > 1024.
http://kamailio.org/docs/modules/devel/modules/tls.html#certificate
 However, this seems to be the opposite of what virtually all security
experts are now saying: most people believe 2048 is bare minimum and
4096 is the better choice for new deployments where no legacy clients
might exist

- also related the above issue, the doc says `bytes', I think it means
to say 1024 bits

- is there a compelling reason to use hard-coded IP addresses for SIP
config files?  For all my apps that have special IP requirements, I
always create dedicated DNS names for each of my virtual/interface IPs.
 Then I like to put that dedicated DNS name (rather than just the
hostname) in the config file.  The listen= directive in kamailio.cfg
doesn't appear to support this though.

- DB setup - I notice that the kamdbctl script expects to make databases
and make tables in one step.  It is not unusual for a security-conscious
admin to deny DBA access from app servers (e.g. the server where
kamailio is installed).  Maybe kamdbctl needs an option to skip DB
creation, and just do table creation?  I found I could achieve this just
by editing:

/usr/lib/kamailio/kamctl/kamdbctl.mysql

and commenting the `exit 1' line in this code:
if [ $? -ne 0 ] ; then
        merr "Creating core database and grant privileges failed!"
        #exit 1
fi

- an alternative solution might be to modify kamdbctl so that it just
connects in read-only mode to make any checks, writes all the DDL
statements to a file that the SIP admin can give to their DBA (or even
if it is the same person, they may have a standalone MySQL box, and they
don't want to install all of kamdbctl on that box)