netdev - Re: [PATCH 00/26] IPVS: Add first IPv6 support to IPVS.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f4845fc0806151714r515545b1l443200d3377b59ad@mail.gmail.com>
Date:	Mon, 16 Jun 2008 02:14:00 +0200
From:	"Julius Volz" <juliusv@...gle.com>
To:	"Patrick McHardy" <kaber@...sh.net>
Cc:	"Simon Horman" <horms@...ge.net.au>,
	"Vince Busam" <vbusam@...gle.com>,
	"Ben Greear" <greearb@...delatech.com>, lvs-devel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH 00/26] IPVS: Add first IPv6 support to IPVS.

On Fri, Jun 13, 2008 at 5:14 PM, Patrick McHardy <kaber@...sh.net> wrote:
> Julius Volz wrote:
>> As for compatibility and extensibility, how is that best achieved with
>> netlink? I've seen some examples copy whole C structs into netlink
>> datagrams, but that is obviously what we don't want anymore. So the
>> way to go seems to be to transfer each struct field as a separate
>> netlink attribute, right?
>
> Yes. You can also group those which belong together logically
> in nested attributes.

Thanks. I've now looked closer at Netlink and read the Genetlink implementation.

For the new IPVS interface, is there a preference for the granularity
of the top-level Genetlink operations?

I see three naive possibilities (one Genetlink op per line), if we
start out with a straight mapping from the old API to the new one:

a)
SET - covers all of previous IP_VS_SO_SET_*
GET - covers all of previous IP_VS_SO_GET_*

b) more split up
ADD - services and destinations
EDIT - services and destinations
DEL - services and destinations
SETTIMEOUT
STARTDAEMON
STOPDAEMON
ZERO
(+ granular GET commands...)

c) totally split up
ADD_SVC
ADD_DEST
EDIT_SVC
EDIT_DEST
DEL_SVC
DEL_DEST
SETTIMEOUT
STARTDAEMON
STOPDAEMON
ZERO
(+ granular GET commands...)

I find http://www.linuxfoundation.org/en/Net:Generic_Netlink_HOWTO saying:
===========================
Operation Granularity

While it may be tempting to register a single operation for a Generic
Netlink family and multiplex multiple sub-commands on the single
operation, this is strongly discouraged for security reasons.
Combining multiple behaviors into one operation makes it difficult to
restrict the operations using the existing Linux kernel security
mechanisms.
===========================

Option c) looks reasonable to me and also seems easy to handle in
general. Is this the way to go? Or do we want the interface to look
completely different this time?

Julius

-- 
Google Switzerland GmbH
--
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