[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140502.152441.695810627123047.davem@davemloft.net>
Date: Fri, 02 May 2014 15:24:41 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: lorenzo@...gle.com
Cc: davidn@...idnewall.com, netdev@...r.kernel.org,
hannes@...essinduktion.org, jpa@...gle.com
Subject: Re: [RFC net-next 0/4] Support UID range routing.
From: Lorenzo Colitti <lorenzo@...gle.com>
Date: Sat, 3 May 2014 04:15:38 +0900
> On Tue, Apr 29, 2014 at 4:01 AM, Lorenzo Colitti <lorenzo@...gle.com> wrote:
>> Basically, what this patch calls "UID" is what the xt_owner module and
>> xt_LOG iptables modules consider to be the "owner" of a socket, what
>> nfqueue presents as the user ID, what shows up in
>> /proc/net/{udp,tcp,raw} in the "uid" column, etc. In most cases this
>> is the effective UID that made the call to socket() or accept().
>>
>> This patch allows using that concept in routing. This can be done
>> today with "iptables -m owner --uid-owner 12345 -j MARK --set-mark
>> 0xbeef; ip rule from fwmark 0xbeef lookup 100", but that has the
>> limitations I set out in my original message (e.g., incorrect source
>> address).
>
> did that help clarify what I'm proposing here? Does this patch still
> seem misguided to you even though its semantics match existing
> functionality?
I understand what you're trying to achieve, but it still leaves a very
bad taste in my mouth.
And I question whether you absolutely cannot get the desired source
address set with appropriate adjustments to the netfilter config,
netfilter can mangle the packet any way you desire it to so why can't
it do so to the source address?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists