Hello Nikolay, thanks for having a look.
Nikolay Sturm wrote on Fri, Dec 26, 2008 at 09:37:16AM +0100: > We have two ports explicitly allowing binding to 0.0.0.0:0, > devel/mico and x11/gnustep/base. I first looked at devel/mico. > How do these cope with your proposed change? > Does denying bind(2) as suggested > and removing their local filter break them? Yes, removing the local filter breaks the mico build. The mico idl insists on listening. Full failing build log: http://www.studis.de/Software/mico-2.3.6p3-fail.log If i understand correctly, local systrace.filter files override the global systrace.filter in infrastructure/db. Thus, if you apply my patch to infrastructure/db/systrace.filter, but just leave devel/mico/systrace.filter as it is, you can build mico as usual. Full succeeding build log: http://www.studis.de/Software/mico-2.3.6p3-ok.log Tested on i386 and sparc64 -current. NB: It builds, installs and uninstalls; i have no idea what to do with CORBA, i.e. how to run it. (Uh, building mico _does_ take some time.) The same *should* hold for x11/gnustep/base: The local filter overrides my patch, so my patch should change nothing in this case. On the other hand, *if* a port build needs bind("inet-[0.0.0.0]:0"), but it has no local filter, it will crash anyway; my patch just disables the systrace log message explaining the crash and leaves you with whatever the particular application prints as a reaction to the failing bind. Anyway, i just started building x11/gnustep/base, just to make really sure. Yours, Ingo In case you are interested, here are the details of my analysis: In a first phase, the miro build process builds some libraries, then some programs, in particular the Interface Definition Language (idl) compiler. After that, it starts a second phase, building more libraries. This second phase already uses the newly built idl compiler. For example, the first thing built in the second phase are the files CosNaming.h, CosNaming.cc and CosNaming_skel.cc, built with the following commands: schwa...@athene $ pwd /usr/ports/devel/mico/w-mico-2.3.6p3/mico/coss/naming schwa...@athene $ export LD_LIBRARY_PATH=../../orb:../../ir schwa...@athene $ export PATH=../../cpp:/bin:/sbin:/usr/bin:/usr/sbin schwa...@athene $ export PATH=$PATH:/usr/local/bin:/usr/local/sbin schwa...@athene $ ../../idl/idl --c++-skel --name CosNaming \ > ../../include/mico/CosNaming.idl schwa...@athene $ ll CosNaming* -rw-r--r-- 1 schwarze wsrc 67246 Dec 26 22:16 CosNaming.cc -rw-r--r-- 1 schwarze wsrc 22129 Dec 26 22:16 CosNaming.h -rw-r--r-- 1 schwarze wsrc 22498 Dec 26 22:16 CosNaming_skel.cc But if we enforce the systrace.policy in question, native-bind: sockaddr eq "inet-[0.0.0.0]:0" then deny[eacces] the idl compiler fails like this: schwa...@athene $ /bin/systrace -e -i -a -f ../../../systrace.policy \ > /bin/sh -c " \ > ../../idl/idl --c++-skel --name CosNaming \ > ../../include/mico/CosNaming.idl \ > " ../../include/mico/CosNaming.idl:101: internal error IDL:omg.org/CORBA/OBJECT_NOT_EXIST:1.0 (0, not-completed) Let's have a closer look: schwa...@athene $ gdb ../../idl/idl GNU gdb 6.3 [...] This GDB was configured as "i386-unknown-openbsd4.4"... (gdb) break bind Function "bind" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (bind) pending. (gdb) run --c++-skel --name CosNaming ../../include/mico/CosNaming.idl Starting program: /usr/ports/devel/mico/w-mico-2.3.6p3/mico/idl/idl \ --c++-skel --name CosNaming ../../include/mico/CosNaming.idl Breakpoint 2 at 0xbb44512 Pending breakpoint "bind" resolved Breakpoint 2, 0x0bb44512 in bind () from /usr/lib/libc.so.50.0 (gdb) where #0 0x0bb44512 in bind () from /usr/lib/libc.so.50.0 #1 0x0c12c90d in MICO::TCPTransportServer::bind () from ../../orb/libmico2.3.6.so.3.0 #2 0x0c13f8ab in MICO::IIOPServer::listen () from ../../orb/libmico2.3.6.so.3.0 #3 0x0c13fd87 in MICO::IIOPServer::listen () from ../../orb/libmico2.3.6.so.3.0 #4 0x0c116279 in CORBA::ORB_init () from ../../orb/libmico2.3.6.so.3.0 #5 0x1c00a6c4 in main () As far as i understand, the point is the following. Each CORBA application is inherently a network application and wants to listen - already during initialization. Now, the idl compiler itself is a CORBA application. If i understand correctly, just letting these beasts listen as much as they like is the way to go. Hopefully, nobody will be talking to them during bulk builds, anyway.
