[JDEV] jabberd as a proper daemon

[Edmund Lam]

On Wed, 21 Nov 2001, Brian Lalor wrote:

> I'd like to see jabberd fixed up to run as a proper daemon.  jabberd
> should fork once the config file's read in (unless told explicitly not to,
> like apache's -X).
>
   Agreed. When I currently run it (jabberd) over ssh, the ssh
connection doesn't die properly when I logout as jabberd is holding the
tty open.

> There should be a proper install mechanism that puts jabberd in /usr/sbin,
> all the .so's in /usr/lib/jabber, the spool in /var/spool/jabber, config
> in /etc/jabber and log files in /var/log/jabber (all what I'm used to with
> RedHat).
>
   I'd second (or was that third) the idea that jabber should have a
decent build process. Likewise, the .so files should all go in a single
directory. The current approach is difficult from a system
administration perspective.

> I've built my RPM (which I will clean up and make available) to put the
> files in those places, and it works, but it does complain about not being
> able to find the directory it was compiled in.  Not forking makes it more

   Easy fix (for jabber-1.4.1 anyway). In "configure" change

"JHOME=`pwd`"
to
"JHOME=/usr/local/whatever"

   But again, it shows that the build process is broken.

   A temporary hack would be to use:

if [ -z "$JHOME" ]; then
    "JHOME=`pwd`"
fi

or

if [ ! -d "$JHOME" ]; then
    "JHOME=`pwd`"
fi

> difficult to write a RH-compliant init.d script.  It would also be nice to
> have jabberd run as a non-root user; there's no need for it to run as
> root, and if (God forbid) an exploit was found to exist, this would save
> some headache.
>
   There is no need to run jabber as a root user as it listens on port
5222. Unless you run other extensions which I don't.

   However, what I'd like to add is an ability for root to run jabber
chroot'ed as a normal user. Like named's -u and -t options. The best
I've got now is a normal user in a non-chroot environment. However, if
jabber gets breached, an attacker could get a user shell-account. If
jabber runs as nobody in a chroot however...

   And while I admire the abilities of the jabber developers, we *know*
there are holes in jabber -- right?. Any program this big and a network
daemon at that -- it's just a matter of time.

> Has anyone already looked into doing these things?  I *might* have some
> time over the long weekend to hack on this a bit if I know where to start.
> I guess another appropriate question would be "why hasn't this been done
> already?"  If there are valid reasons, I'll save myself some coding time,
> but otherwise, I should be able to dive in and give it a whirl.
>
   I'll like to work on something similar. But I'd like to know whose's
code I'm stepping on. In all probability, there are very good reasons
why things are being done as they are now. However, I do believe the
code is too complex to audit from a security perspective. While jabber
works after a fashion, there are many features/safeguards which I'd
like for peace-of-mind.

For example:
- simplified command-line parsing. Is there really a need to allow
  sysadmin to add command-line parameters by changing the configuration
  file? Does that mean jabberd will never have a proper man page? Why
  not just use getopt(). The current jabber also allows for command lines
  like "jabber -a -b" to be interpreted as "jabber -a \-b". While this is
  explained in the FAQ, it is counter-intuitive and the opposite of other
  programs.
- add chroot() support.
- add setuid()/setgid() support.

   I believe I can most of the stuffs. However, like Brian, I'd like to
hear reasons why I shouldn't dive in and start coding. Furthermore,
would a decent patch implementing the above ideas be applied?

Thanks

Eddie