[Olsr-dev] making olsrd a "Position Independent Executable" i.e. gcc -pie -fPIE

Hans-Christoph Steiner (spam-protected)
Wed Oct 3 17:49:57 CEST 2012

On 10/03/2012 03:16 AM, Henning Rogge wrote:
> On Wed, Oct 3, 2012 at 2:48 AM, Hans-Christoph Steiner
> <(spam-protected)> wrote:
>> Any hazards to -O2 in olsrd?  I see that its not there by default, yet
>> is is a very common default.  Debian sets -O2 by default, for example.
> I think most OLSR.org instances are OpenWRT... and they are "-Os".
> But we could easily make the debian package go "-O2".
> I prefer the "default compilation" to be one with debug options
> enabled. If someone compiles his own Olsr, it helps to hunt for bugs.

-O2 enables some security features by default like -D_FORTIFY_SOURCE=2,
and since olsrd is running as root, it should take extra steps to be secure.

IMHO, the default compilation should be build that is most commonly
used.  Every other software package that I can think of defaults to a
reasonable deployable build, and uses some option to enable debug
builds.  But I don't work with a lot of routing software these days, so
maybe that world is different.

I think about it this way: for someone who just wants to run olsrd on
their system, then all they should do is "make && make install" and have
a working install with defaults for running install.  They will have no
reason to learn about the build system since "make install" did its job.
 If someone is working on olsrd itself, then they already know something
more about the build system, so turning on debug mode is a simple matter.

>>> Yes, unfortunately we cannot give root away after initializing... even
>>> if we could hand over the rtnetlink socket to another process, OLSRd
>>> needs the capability to open new sockets when an interface goes up.
>> For something like the plugins that listen on a port, it seems
>> especially hazardous to have them running as root, and I see no reason
>> that txtinfo, httpinfo, jsoninfo, etc. need root privs once they've
>> opened their sockets.
> Olsrd has only a single thread/process, so there is nothing the
> plugins can drop because the root core still need the capabilities.
> We should experiment if we can keep using a RTNetlink socket if we
> move the socket over to a thread which has no root-rights.

>> I'll bring up sshd again since it is one process that has separate parts
>> running as root and unprivileged users. It also handles changing
>> interfaces, for example, if you have sshd running and turn on your wifi,
>> then you can ssh to the IP of the wifi without having to reset sshd.  I
>> haven't read the code so I can't point out the relevant bits but I do
>> know its behaving the way that I think olsrd should.
> I have been thinking about this for the new framework, the networking
> code API is a bit more strict there which should make such a
> separation easier. But I decided to delay the decision until I have a
> running routing agent. ^^

A quick check of OpenSSH sources shows that threads are only used for
PAM auth:

(spam-protected) openssh-5.9p1 $ grep pthread * */*
auth-pam.c:#include <pthread.h>
auth-pam.c: * Avoid namespace clash when *not* using pthreads for
systems *with*
auth-pam.c: * pthreads, which unconditionally define pthread_t via
auth-pam.c:typedef pthread_t sp_pthread_t;
auth-pam.c:typedef pid_t sp_pthread_t;
auth-pam.c:	sp_pthread_t	 pam_thread;
auth-pam.c:		return;	/* terminated by pthread_cancel */
auth-pam.c:pthread_exit(void *value)
auth-pam.c:pthread_create(sp_pthread_t *thread, const void *attr,
auth-pam.c:pthread_cancel(sp_pthread_t thread)
auth-pam.c:pthread_join(sp_pthread_t thread, void **value)
auth-pam.c:	pthread_exit(NULL);
auth-pam.c:	pthread_exit(NULL);
auth-pam.c:	return (NULL); /* Avoid warning for non-pthread case */
auth-pam.c:		pthread_cancel(ctxt->pam_thread);
auth-pam.c:		pthread_join(ctxt->pam_thread, NULL);
auth-pam.c:	if (pthread_create(&ctxt->pam_thread, NULL, sshpam_thread,
ctxt) == -1) {
openbsd-compat/getrrsetbyname.c:/* We don't need multithread support here */

I think the general model with sshd is that there is a process per
session.  But other than that, it seems like they are doing something
that could work well in olsrd.


More information about the Olsr-dev mailing list