[PATCH 4/4] ntdll: Fixup ICMP packet id if SOCK_DGRAM fallback is used.

[Zebediah Figura]

On 7/8/22 18:05, Paul Gofman wrote:
> On 7/8/22 17:24, Zebediah Figura wrote:
>>
>> This is awfully complicated. Would it be possible to just get the
>> kernel to give us the right ID back, perhaps by adding a new socket
>> option?
> 
> I honestly have no idea how easy is to change anything in Linux kernel
> in this regard but my guess is that not easy at all. I think kernel does
> not have that ID when receiving the reply packet. It fixes up the ID in
> the sent ICMP packet. And I guess it does it for security reasons,
> probably to make sure the unprivileged user can't interfere with other
> ping users (including root) by spoofing the ICMP ID which might
> interefere with them. So given how that was done already I doubt the
> change allowing to do what we want in a straightforward way can be accepted.

Hmm, okay. I feel like there's potentially an argument for "if you're 
going to fix it up, can you please fix it up on both ends so it's 
transparent to the user", but maybe it's not a compelling one.

I guess the thing is, if there's a way to modify the kernel, even if 
it's just for Wine, and it's less ugly than modifying Wine itself, it 
may be worth looking into. It's not the first time that we've had to 
introduce options into the kernel (although granted, the only other case 
I know of offhand was something that I believe couldn't have been done 
in user space, viz. binding UDP sockets to a specific interface).

>> For that matter, I guess the same goes for the first part of the
>> series—if we could get a way to get a SOCK_RAW + IPPROTO_ICMP socket,
>> presumably one where the kernel filters out anything unsafe, that'd be
>> a lot nicer than fixing things up in Wine...
>>
> Same here. For some reason that was made on top of DGRAM instead of
> allowing ICMP on RAW. I guess that probably to hide raw IP header
> instead of screening / fixing up it for security reasons (and maybe
> something else to it which I not immediately know of).
> 

Yeah, it'd be nice to know if there is an underlying reason that the 
kernel doesn't want to just filter out unsafe headers, though, since as 
above that'd be a lot easier for us.