Removing NET_NEEDS_GIANT: first patch

[Robert Watson]

On Fri, 27 Jul 2007, Christian S.J. Peron wrote:

>> Index: ip_divert.c
>> ===================================================================
>> RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/ip_divert.c,v
>> retrieving revision 1.128
>> diff -u -r1.128 ip_divert.c
>> --- ip_divert.c	11 May 2007 10:20:50 -0000	1.128
>> +++ ip_divert.c	27 Jul 2007 14:25:09 -0000
>> @@ -61,6 +61,7 @@
>>   #include <vm/uma.h>
>>
>>   #include <net/if.h>
>> +#include <net/netisr.h>
>>   #include <net/route.h>
>>
>>   #include <netinet/in.h>
>> @@ -378,7 +379,7 @@
>>   				    ((so->so_options & SO_DONTROUTE) ?
>>   				    IP_ROUTETOIF : 0) |
>>   				    IP_ALLOWBROADCAST | IP_RAWOUTPUT,
>> -				    inp->inp_moptions, NULL);
>> +				    inp->inp_moptions, inp);
>
> Here we are passing the inp associated with the divert socket.  I am not 
> sure how accurate this is, since it's quite possible that the packet could 
> belong to another TCP/UDP socket owned by a completely different user and 
> socket for that matter.
>
> This will result in the firewalls attributing the packet to the user of 
> whoever created the divert socket (probably root), instead of attributing 
> the packet to the subject who created the original TCP/UDP socket.

Hmm, you are, of course, entirely right.  This would fix the locking problem 
but lead to incorrect results in processing.  The right fix here may be to 
arrange to drop all the locks, which means doing an m_dup of the options, 
before calling ip_output(), which would allow ip_output() to acquire whatever 
locks it needs.

I wonder if we have some similar issues with raw ICMP sockets?

Robert N M Watson
Computer Laboratory
University of Cambridge