All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: netdev@vger.kernel.org, selinux@tycho.nsa.gov,
	davem@davemloft.net, sds@epoch.ncsc.mil, jmorris@redhat.com,
	pratt@argus-systems.com
Subject: Re: [PATCH 2/7] NetLabel: core network changes
Date: Fri, 28 Jul 2006 15:08:44 -0400	[thread overview]
Message-ID: <44CA60BC.1030503@hp.com> (raw)
In-Reply-To: <20060728185825.GG14627@postel.suug.ch>

Thomas Graf wrote:
> * Paul Moore <paul.moore@hp.com> 2006-07-28 14:39
> 
>>It sounds like you main concern is that I'm not using the netlink
>>attribute interfaces, yes?  I looked at using those originally but
>>decided not to use them for the following reasons:
>>
>> 1. They are listed as "optional" in the documents I read
>> 2. They add at least an extra 32 bits to each attribute
>> 3. There seems to be plenty of users in net/ipv4 who do not make
>>    use of attributes (a *quick* look again reveals none)
>> 4. Since I'm reading messages from userspace I can't trust the
>>    message contents regardless of it's use of attributes
>> 5. Harder to work with in userspace without using a netlink
>>    library, which would create an extra dependency for tools which
>>    talk to the NetLabel subsystem
>>
>>Basically, I saw no requirement to use the netlink attributes and no
>>advantage so I didn't.  Is this reasonable, or do you feel the use of
>>attributes is a requirement?
> 
> Not a requirement but I would encourage it. Almost all netlink
> families are using attributes with a few exceptions. We just
> used to call them rtattr defined in rtnetlink.h before the new
> api was added. There is one huge advantage in using attributes
> which is that your protocol is extendable without breaking binary
> interfaces.
> 
> What I'm refering to primarly are the existing functions to write
> netlink and genetlink headers etc.

Okay.  Thanks for your feedback but unless I hear from others that this
is a requirement I think I'm going to leave the code as written for the
reasons I listed above.  I won't argue the fact that attributes may make
life easier when extending existing messages/interfaces but I think the
existing NetLabel message format as well as the generic netlinks
versioning of each message should allow plenty of room for growth in the
future (if needed).

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <paul.moore@hp.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: netdev@vger.kernel.org, selinux@tycho.nsa.gov,
	davem@davemloft.net, sds@epoch.ncsc.mil, jmorris@redhat.com,
	pratt@argus-systems.com
Subject: Re: [PATCH 2/7] NetLabel: core network changes
Date: Fri, 28 Jul 2006 15:08:44 -0400	[thread overview]
Message-ID: <44CA60BC.1030503@hp.com> (raw)
In-Reply-To: <20060728185825.GG14627@postel.suug.ch>

Thomas Graf wrote:
> * Paul Moore <paul.moore@hp.com> 2006-07-28 14:39
> 
>>It sounds like you main concern is that I'm not using the netlink
>>attribute interfaces, yes?  I looked at using those originally but
>>decided not to use them for the following reasons:
>>
>> 1. They are listed as "optional" in the documents I read
>> 2. They add at least an extra 32 bits to each attribute
>> 3. There seems to be plenty of users in net/ipv4 who do not make
>>    use of attributes (a *quick* look again reveals none)
>> 4. Since I'm reading messages from userspace I can't trust the
>>    message contents regardless of it's use of attributes
>> 5. Harder to work with in userspace without using a netlink
>>    library, which would create an extra dependency for tools which
>>    talk to the NetLabel subsystem
>>
>>Basically, I saw no requirement to use the netlink attributes and no
>>advantage so I didn't.  Is this reasonable, or do you feel the use of
>>attributes is a requirement?
> 
> Not a requirement but I would encourage it. Almost all netlink
> families are using attributes with a few exceptions. We just
> used to call them rtattr defined in rtnetlink.h before the new
> api was added. There is one huge advantage in using attributes
> which is that your protocol is extendable without breaking binary
> interfaces.
> 
> What I'm refering to primarly are the existing functions to write
> netlink and genetlink headers etc.

Okay.  Thanks for your feedback but unless I hear from others that this
is a requirement I think I'm going to leave the code as written for the
reasons I listed above.  I won't argue the fact that attributes may make
life easier when extending existing messages/interfaces but I think the
existing NetLabel message format as well as the generic netlinks
versioning of each message should allow plenty of room for growth in the
future (if needed).

-- 
paul moore
linux security @ hp

  reply	other threads:[~2006-07-28 19:08 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-17 15:52 [PATCH 0/7] Updated patchset w/James' comments paul.moore
2006-07-17 15:52 ` paul.moore
2006-07-17 15:52 ` [PATCH 1/7] NetLabel: documentation paul.moore
2006-07-17 15:52   ` paul.moore
2006-07-28  7:51   ` David Miller
2006-07-28 18:52     ` Paul Moore
2006-07-28 18:52       ` Paul Moore
2006-07-17 15:52 ` [PATCH 2/7] NetLabel: core network changes paul.moore
2006-07-17 15:52   ` paul.moore
2006-07-28  7:55   ` David Miller
2006-07-28 18:45     ` Paul Moore
2006-07-28 18:45       ` Paul Moore
2006-07-28 19:55       ` David Miller
2006-07-28 11:24   ` Thomas Graf
2006-07-28 17:58     ` Paul Moore
2006-07-28 17:58       ` Paul Moore
2006-07-28 18:12       ` Thomas Graf
2006-07-28 18:39         ` Paul Moore
2006-07-28 18:39           ` Paul Moore
2006-07-28 18:58           ` Thomas Graf
2006-07-28 19:08             ` Paul Moore [this message]
2006-07-28 19:08               ` Paul Moore
2006-07-28 19:43               ` Evgeniy Polyakov
2006-07-28 19:58               ` David Miller
2006-07-28 20:09                 ` Paul Moore
2006-07-28 20:09                   ` Paul Moore
2006-07-28 20:56                   ` David Miller
2006-07-28 20:59                     ` Paul Moore
2006-07-28 20:59                       ` Paul Moore
2006-07-17 15:52 ` [PATCH 3/7] NetLabel: CIPSOv4 engine paul.moore
2006-07-17 15:52   ` paul.moore
2006-07-28  7:56   ` David Miller
2006-07-17 15:52 ` [PATCH 4/7] NetLabel: core NetLabel subsystem paul.moore
2006-07-17 15:52   ` paul.moore
2006-07-17 15:52 ` [PATCH 5/7] NetLabel: CIPSOv4 and Unlabeled packet integration paul.moore
2006-07-17 15:52   ` paul.moore
2006-07-17 15:52 ` [PATCH 6/7] NetLabel: SELinux support paul.moore
2006-07-17 15:52   ` paul.moore
2006-07-17 15:52 ` [PATCH 7/7] NetLabel: tie NetLabel into the Kconfig system paul.moore
2006-07-17 15:52   ` paul.moore
2006-07-17 18:48 ` [PATCH 0/7] Updated patchset w/James' comments Valdis.Kletnieks
2006-07-17 19:00   ` Paul Moore
2006-07-17 19:00     ` Paul Moore
  -- strict thread matches above, loose matches on Subject: below --
2006-07-31 12:43 [PATCH 2/7] NetLabel: core network changes Venkat Yekkirala
2006-07-31 12:43 ` Venkat Yekkirala
2006-07-31 14:16 ` Paul Moore
2006-07-31 14:16   ` Paul Moore
2006-07-29 16:34 Venkat Yekkirala
2006-07-29 16:34 ` Venkat Yekkirala
2006-07-29 21:03 ` Paul Moore
2006-07-29 21:03   ` Paul Moore
2006-07-14 18:57 [PATCH 0/7] Latest NetLabel patch for 2.6.19 paul.moore
2006-07-14 18:57 ` [PATCH 2/7] NetLabel: core network changes paul.moore
2006-07-14 18:57   ` paul.moore
2006-07-14 23:34   ` James Morris
2006-07-14 23:34     ` James Morris
2006-07-14 23:36     ` David Miller
2006-07-15 14:48     ` Paul Moore
2006-07-15 14:48       ` Paul Moore

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=44CA60BC.1030503@hp.com \
    --to=paul.moore@hp.com \
    --cc=davem@davemloft.net \
    --cc=jmorris@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pratt@argus-systems.com \
    --cc=sds@epoch.ncsc.mil \
    --cc=selinux@tycho.nsa.gov \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.