From: ebiederm@xmission•com (Eric W. Biederman)
To: Hannes Frederic Sowa <hannes@stressinduktion•org>
Cc: David Ahern <dsa@cumulusnetworks•com>,
netdev@vger•kernel.org, shm@cumulusnetworks•com,
roopa@cumulusnetworks•com, gospo@cumulusnetworks•com,
jtoppins@cumulusnetworks•com, nikolay@cumulusnetworks•com,
ddutt@cumulusnetworks•com, nicolas.dichtel@6wind•com,
stephen@networkplumber•org, hadi@mojatatu•com,
davem@davemloft•net, svaidya@brocade•com, mingo@kernel•org,
luto@amacapital•net
Subject: Re: [PATCH net-next 14/16] net: Add sk_bind_dev_if to task_struct
Date: Tue, 28 Jul 2015 08:54:15 -0500 [thread overview]
Message-ID: <87k2tktmk8.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <1438085969.25794.14.camel@stressinduktion.org> (Hannes Frederic Sowa's message of "Tue, 28 Jul 2015 14:19:29 +0200")
Hannes Frederic Sowa <hannes@stressinduktion•org> writes:
> Hello Eric,
>
> On Mon, 2015-07-27 at 15:33 -0500, Eric W. Biederman wrote:
>> David Ahern <dsa@cumulusnetworks•com> writes:
>>
>> > Allow tasks to have a default device index for binding sockets. If
>> > set
>> > the value is passed to all AF_INET/AF_INET6 sockets when they are
>> > created.
>> >
>> > The task setting is passed parent to child on fork, but can be set
>> > or
>> > changed after task creation using prctl (if task has CAP_NET_ADMIN
>> > permissions). The setting for a socket can be retrieved using
>> > prctl().
>> > This option allows an administrator to restrict a task to only
>> > send/receive
>> > packets through the specified device. In the case of VRF devices
>> > this
>> > option restricts tasks to a specific VRF.
>> >
>> > Correlation of the device index to a specific VRF, ie.,
>> > ifindex --> VRF device --> VRF id
>> > is left to userspace.
>>
>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission•com>
>>
>> Because it is broken by design. Your routing device is only safe for
>> programs that know it's limitations it is not appropriate for general
>> applications.
>>
>> Since you don't even seen to know it's limitations I think this is a
>> bad path to walk down.
>
> Can you please elaborate about the broken by design?
>
> Different operating systems are already using this approach with good
> success. I read your other mail regarding isolation of different VRFs
> and I agree that all code which persists state depending solely on the
> IP address is affected by this and this must be dealt with and fixed
> (actually, there aren't too many).
The size of struct net would tend to disagree with the assertion that
there are not too many.
> But I wouldn't call that broken by design. This stuff will get fixed
> like e.g. cross-talk between fragmentation queues, icmp rate limiters
> etc, which could already happen in the past.
>
> What is your opinion on the fundamental approach only from a user
> perspective? Do you think that is broken, too?
I think promising something to userspace that a design can not deliver
is a fundamental problem.
Eric
next prev parent reply other threads:[~2015-07-28 14:00 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 18:30 [net-next 0/16] Proposal for VRF-lite - v3 David Ahern
2015-07-27 18:30 ` [PATCH net-next 01/16] net: Refactor rtable allocation and initialization David Ahern
2015-07-27 18:30 ` [PATCH net-next 02/16] net: export a few FIB functions David Ahern
2015-07-27 18:30 ` [PATCH net-next 03/16] net: Introduce VRF related flags and helpers David Ahern
2015-07-27 18:30 ` [PATCH net-next 04/16] net: Use VRF device index for lookups on RX David Ahern
2015-07-27 18:30 ` [PATCH net-next 05/16] net: Use VRF device index for lookups on TX David Ahern
2015-07-27 18:30 ` [PATCH net-next 06/16] net: Tx via VRF device David Ahern
2015-07-27 18:31 ` [PATCH net-next 07/16] net: Add inet_addr lookup by table David Ahern
2015-07-27 18:31 ` [PATCH net-next 08/16] net: Fix up inet_addr_type checks David Ahern
2015-07-27 18:31 ` [PATCH net-next 09/16] net: Add routes to the table associated with the device David Ahern
2015-07-27 18:31 ` [PATCH net-next 10/16] net: Use passed in table for nexthop lookups David Ahern
2015-07-27 18:31 ` [PATCH net-next 11/16] net: Use VRF device index for socket lookups David Ahern
2015-07-27 18:31 ` [PATCH net-next 12/16] net: Add ipv4 route helper to set next hop David Ahern
2015-07-27 18:31 ` [PATCH net-next 13/16] net: Introduce VRF device driver - v2 David Ahern
2015-07-27 20:01 ` Nikolay Aleksandrov
2015-07-28 16:22 ` David Ahern
2015-07-27 18:31 ` [PATCH net-next 14/16] net: Add sk_bind_dev_if to task_struct David Ahern
2015-07-27 20:33 ` Eric W. Biederman
2015-07-28 12:19 ` Hannes Frederic Sowa
2015-07-28 13:54 ` Eric W. Biederman [this message]
2015-07-28 14:20 ` Hannes Frederic Sowa
2015-07-28 16:01 ` Eric Dumazet
2015-07-28 16:07 ` David Ahern
2015-07-28 16:52 ` Eric Dumazet
2015-07-28 15:25 ` Andy Lutomirski
2015-07-28 16:11 ` David Ahern
2015-07-28 17:12 ` Tom Herbert
2015-07-27 18:31 ` [PATCH net-next 15/16] net: Add chvrf command David Ahern
2015-07-27 18:31 ` [PATCH] iproute2: Add support for VRF device David Ahern
2015-07-27 20:30 ` [net-next 0/16] Proposal for VRF-lite - v3 Eric W. Biederman
2015-07-28 16:02 ` David Ahern
2015-07-28 17:07 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k2tktmk8.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=ddutt@cumulusnetworks$(echo .)com \
--cc=dsa@cumulusnetworks$(echo .)com \
--cc=gospo@cumulusnetworks$(echo .)com \
--cc=hadi@mojatatu$(echo .)com \
--cc=hannes@stressinduktion$(echo .)org \
--cc=jtoppins@cumulusnetworks$(echo .)com \
--cc=luto@amacapital$(echo .)net \
--cc=mingo@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nicolas.dichtel@6wind$(echo .)com \
--cc=nikolay@cumulusnetworks$(echo .)com \
--cc=roopa@cumulusnetworks$(echo .)com \
--cc=shm@cumulusnetworks$(echo .)com \
--cc=stephen@networkplumber$(echo .)org \
--cc=svaidya@brocade$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox