Re: [PATCH 4/4] iptables: libxt_owner

[Patrick McHardy <kaber@trash.net>]

Jan Engelhardt wrote:
> On Nov 25 2007 16:22, Patrick McHardy wrote:
>> Jan Engelhardt wrote:
>>> +static void owner_mt_help(void)
>>> +{
>>> +	printf(
>>> +"owner match v%s options:\n"
>>> +"[!] --uid-owner userid     Match local UID\n"
>>> +"[!] --gid-owner groupid    Match local GID\n"
>>> +"[!] --socket-exists        Match if socket exists\n"
>>> +"[!] --filp-exists          Match if filp exists\n"
>>> +"\n",
>>> +IPTABLES_VERSION);
>> The filp-exists option strikes me as useless, what would the
>> use case be? For the socket-exists option, I'd prefer for the
>> owner match to simply accept no further option, i.e. "-m owner".
>>
> 
> 
> hasSocket hasFilp whatCouldItBe
> ===============================
>        0       0  forwarded packet
>        1       0  ping, nfs client, nfsd
>        1       1  real connection
> 
> However, you mentioned that encapsulated (socket=1,filp=1) traffic
> will show up without a "socket", but did you actually mean socket
> or filp?

No, I was talking about forwarded encapsulated traffic showing
up in the output chain (we were talking about locally outgoing
packets). These packets have neither.

> I just checked, and xfrm'ed traffic has the same properties as before 
> the transformation.
> 
> So actually socket-exists is the useless one, as there is always a 
> socket in any normal case.
> 
> What do you think?

I think both (together) expose too much of the internals and are
not very useful. There is no guarantee that nfsd will behave the
same way tommorrow. The "socket exists" option is IMO useful for
one single purpose, distinguish packets that originate from
local sockets from packets that are forwarded in the OUTPUT
and POSTROUTING chains in cases where the source address can't
be used, like tunneling. But before it gets too ugly I'd
rather not support it.