The number of file descriptors enforced by setrlimit() can now be set at
compile time using a flag. The flag defaults to 0 on Linux and -1
everywhere else:
XMPPIPE_SANDBOX=XMPPIPE_SANDBOX_RLIMIT \
XMPPIPE_SANDBOX_RLIMIT_NOFILE=-1 \
make
The meaning of the XMPPIPE_SANDBOX_RLIMIT_NOFILE is:
* -1 : set rlim_cur/rlim_max to the lowest allocated file desciptor
* >=0: set rlim_cur/rlim_max to this number
On some platforms, setting rlim_cur below the value of the highest
allocated fd may interfere with polling. See commit a34d5766c5 for
details.
Prepare for sandboxing the xmppipe process by adding a function called
after all file descriptors are allocated.
The intent of the sandbox is to limit the xmppipe process to the role
of a component in a shell pipeline: reading from stdin, reading/writing
to the XMPP socket and writing to stdout. Any activity not involved with
using stdio should force the process to exit.
The sandbox function will vary based on the capabilities of the
platform. The default sandbox function does nothing.
Limitations of the sandbox:
Probably the biggest risk is in session establishment:
* the TLS handshake
* the XML parsing
The sandbox is enforced after the TLS connection is established, i.e.,
after the file descriptor for the XMPP session is allocated and so has no
effect on the TLS handshake or the initial XMPP handshake.
Possibly an initial sandbox could be setup for the connection phase
followed by a stricter sandbox for the stdio phase.
Use uuid_create(3) and uuid_to_string(3) to create the message id on
BSDs. Only tested on FreeBSD but should work on OpenBSD and NetBSD.
Add untested support for compiling on Solaris and Mac OS X:
* SmartOS has libuuid installed by default with rsyslog via pkgsrc
* Mac OS X has libuuid as part of libSystem:
http://lists.apple.com/archives/unix-porting/2009/Aug/msg00006.html
Implement flow control by monitoring the number of unacked stream
requests and the number of unprocessed stanzas. If either exceeds a user
controlled limit, xmppipe will stop reading from stdin. Further stream
requests will be generated whenever the keepalive timeout is reached and
an XMPP ping is sent.
ejabberd/mongooseim will close the connection if there are about 5
unacked stream requests. xmppipe should probably do the same thing.
With these changes, binaries can be reliably (but slowly) sent over
XMPP. ssh over XMPP is also working reliably (with light testing). Because
of the increase in size due to base64 encoding, the buffer size needs
to be reduced so the encoded message is under 4k (-m 1024 is ok).
Optionally base64 encode data sent to and from a conference, allowing
transfer of binary data.
This could also be accomplished by piping in base64 encoded data:
base64 /bin/ls | xmppipe
However the base64 command does not work with streams of data.
Check for errors on libstrophe functions that return non-void. Some of
the funs have undocumented failure conditions (e.g.,
xmpp_stanza_copy()). Others return less than zero or enum values. To
account for future discoveries, use a wrapper instead of a macro.
Request stream management for the session by default. The rate of requests
and acks is controlled by the -I option. With stream management, the
client can check when all stanzas have been flushed to the server. For
example, the following works:
cat /path/textfile | xmppipe -o transfer -r sender
# on another system
xmppipe -o transfer -r receiver > tmpfile
The behaviour is to always attempt enabling stream management. The XEP
is ambiguous about the response to an enable when stream management is
not offered. Presumably the server will respond with "failure".
So the code should probably have 2 checks:
* if stream management is offered as a feature, send an enable
* if the server responds with "enabled", handle requests
Set a limit on the number of pings without a reply and exit if the limit
is reached. Useful for detecing broken network connections due to
network changes.
The default configuration will take about 4 minutes to detect failure
(1 keepalive every 60 seconds, tolerate 3 failures).
Add a ID per message. Seems to fix the duplicate messages seen with MUCs
on the Conversations android client whenever the network is switched
(e.g., from wifi to cell).
Introduce a dependency on Linux's libuuid which introduces portability
issues. However, it should be simple to add support for the BSD UUID
interface.
libuuid was used because it is a fast and simple way of generating
a unique id. Realistically, the ID only needs to be unique within
the MUC and so could probably be replaced with an sprintf() combining
time of day, PID and a random number.
Michael Santos