jailkit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Jailkit-dev] Enhancements to jk_socketd.c


From: Rene S. Hollan
Subject: [Jailkit-dev] Enhancements to jk_socketd.c
Date: Mon, 24 Dec 2007 01:41:47 -0800

Hi all.

I had the need to make some enhancements to jk_socket.c and thought to
share them. http://rhollan.clearwire.net/jk_socketd.c has a revised
version. wget http://rhollan.clearwire.net/jk_socketd.c should work to
retrieve it.

Enjoy.

Basically,

Extensive modifications to support the following:

1. Use of an arbitrary target *nix socket other than /dev/log.

2. Different target *nix sockets for each source *nix socket.

3. Bidirectional communication between source and target *nix sockets.

4. Multiple simultaneous or sequential connections to any source *nix
socket.

5. Handling of zombie child processes (one child process per connection
per source *nix socket).

6. Replacement of pthreads with processes (which are lightweight under
Linux). This was necessary to handle multiple connections, rather than a
single process that chroots once.

7. Main process runs as root, and no data is transferred until after a
child process is chrooted into a jail as nobody in an empty directory
(same as original code).

8. Multiple source *nix sockets can accept connections in any order.
They don't ALL have to accept one connection before any can transfer
data. (Was this a bug?)

   This was undertaken to permit a non-jailed root daemon jk_socketd to
spawn jailed subprocesses to communicate bidirectionally between *nix
sockets where one and/or the other are written and/or read from a jailed
chrooted process. Communication between jailed processes in DIFFERENT
chroots is possible this way.

   This has been tested using bind 9.3.1 under Ubuntu Gutsy (7.10)
that's running chrooted from the command line to communicate with mysqld
(not chrooted) via jk_socketd for zones in the mysql database. (Bind
9.3.1 supports a SQL backend for some of it's zones.)

   Extensive testing of the command line options was NOT performed.

To do:

1. More hardening. There are too many strdups for my liking (as in more
than none. The occur at configuration time, but still.

2. More consistent logging and message in detached and non-detached
mode, and when DEBUG is defined.

3. More configurable control over operational parameters (like zombie
child process reaping).

4. Fine grained control over source *nix socket ownership and
permissions that are created.

5. Possible limits to simultaneous connections to any one *unix socket,
and aggregate throughput limits.

6. Support for network connections.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]