All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: selinux@tycho.nsa.gov, netdev@vger.kernel.org,
	sds@epoch.ncsc.mil, jmorris@redhat.com
Subject: Re: [PATCH 5/6] NetLabel: rework the Netlink attribute handling (part 2)
Date: Mon, 25 Sep 2006 11:42:03 -0400	[thread overview]
Message-ID: <4517F8CB.1030707@hp.com> (raw)
In-Reply-To: <20060925150625.GP18349@postel.suug.ch>

Thomas Graf wrote:
> * Paul Moore <paul.moore@hp.com> 2006-09-25 10:13
> 
>>>>-	ret_val = netlbl_netlink_snd(ans_skb, info->snd_pid);
>>>>+	switch (doi_def->type) {
>>>>+	case CIPSO_V4_MAP_STD:
>>>>+		nla_a = nla_nest_start(ans_skb, NLBL_CIPSOV4_A_MLSLVLLST);
>>>>+		if (nla_a == NULL) {
>>>>+			ret_val = -ENOMEM;
>>>>+			goto list_failure_lock;
>>>>+		}
>>>>+		for (iter = 0;
>>>>+		     iter < doi_def->map.std->lvl.local_size;
>>>>+		     iter++) {
>>>>+			if (doi_def->map.std->lvl.local[iter] ==
>>>>+			    CIPSO_V4_INV_LVL)
>>>>+				continue;
>>>
>>>
>>>Can you estimate the number of entries being dumped here and in the cat
>>>list below?
>>>
>>
>>It's too hard to come up with a reasonable estimate without going
>>through the entire list before hand, which in previous messages (might
>>of been off-list) you pointed out as a bad thing.  If you would prefer I
>>can go back to doing it that way?
>  
> Sorry, I didn't make myself clear. I didn't mean to estimate the
> size of the message. The way you're doing it right now is perfectly
> fine. I'm interested in a estimate on how many items are being dumped
> in practice. Less than 1K or a couple of K?
> 
> High order allocations are likely to fail if under pressure while
> using dumpit() allows to reuse memory ressources.

It's hard to get a good idea of the likely usage scenario as I'm not
sure how users will want to configure NetLabel.  However, there is a
possibility of this growing larger than NLMSG_GOODSIZE, which makes
things a bit more difficult.  From what I can see dumpit() requires the
message be within NLMSG_GOODSIZE while a doit() response can be of
arbitrary length; this is why I chose a doit() response.  Even if the
system is under memory pressure I think a failure here is okay as this
is not what I would consider a critical message.

-- 
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: selinux@tycho.nsa.gov, netdev@vger.kernel.org,
	sds@epoch.ncsc.mil, jmorris@redhat.com
Subject: Re: [PATCH 5/6] NetLabel: rework the Netlink attribute handling (part 2)
Date: Mon, 25 Sep 2006 11:42:03 -0400	[thread overview]
Message-ID: <4517F8CB.1030707@hp.com> (raw)
In-Reply-To: <20060925150625.GP18349@postel.suug.ch>

Thomas Graf wrote:
> * Paul Moore <paul.moore@hp.com> 2006-09-25 10:13
> 
>>>>-	ret_val = netlbl_netlink_snd(ans_skb, info->snd_pid);
>>>>+	switch (doi_def->type) {
>>>>+	case CIPSO_V4_MAP_STD:
>>>>+		nla_a = nla_nest_start(ans_skb, NLBL_CIPSOV4_A_MLSLVLLST);
>>>>+		if (nla_a == NULL) {
>>>>+			ret_val = -ENOMEM;
>>>>+			goto list_failure_lock;
>>>>+		}
>>>>+		for (iter = 0;
>>>>+		     iter < doi_def->map.std->lvl.local_size;
>>>>+		     iter++) {
>>>>+			if (doi_def->map.std->lvl.local[iter] ==
>>>>+			    CIPSO_V4_INV_LVL)
>>>>+				continue;
>>>
>>>
>>>Can you estimate the number of entries being dumped here and in the cat
>>>list below?
>>>
>>
>>It's too hard to come up with a reasonable estimate without going
>>through the entire list before hand, which in previous messages (might
>>of been off-list) you pointed out as a bad thing.  If you would prefer I
>>can go back to doing it that way?
>  
> Sorry, I didn't make myself clear. I didn't mean to estimate the
> size of the message. The way you're doing it right now is perfectly
> fine. I'm interested in a estimate on how many items are being dumped
> in practice. Less than 1K or a couple of K?
> 
> High order allocations are likely to fail if under pressure while
> using dumpit() allows to reuse memory ressources.

It's hard to get a good idea of the likely usage scenario as I'm not
sure how users will want to configure NetLabel.  However, there is a
possibility of this growing larger than NLMSG_GOODSIZE, which makes
things a bit more difficult.  From what I can see dumpit() requires the
message be within NLMSG_GOODSIZE while a doit() response can be of
arbitrary length; this is why I chose a doit() response.  Even if the
system is under memory pressure I think a failure here is okay as this
is not what I would consider a critical message.

-- 
paul moore
linux security @ hp

  reply	other threads:[~2006-09-25 15:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-21 16:57 [PATCH 0/6] NetLabel fixes and reworked Netlink interface paul.moore
2006-09-21 16:57 ` paul.moore
2006-09-21 16:57 ` [PATCH 1/6] NetLabel: correct improper handling of non-NetLabel peer contexts paul.moore
2006-09-21 16:57   ` paul.moore
2006-09-21 18:08   ` James Morris
2006-09-21 18:08     ` James Morris
2006-09-21 18:28     ` Paul Moore
2006-09-21 18:28       ` Paul Moore
2006-09-21 16:57 ` [PATCH 2/6] NetLabel: make the CIPSOv4 cache spinlocks bottom half safe paul.moore
2006-09-21 16:57   ` paul.moore
2006-09-21 16:57 ` [PATCH 3/6] NetLabel: change the SELinux permissions paul.moore
2006-09-21 16:57   ` paul.moore
2006-09-21 16:57 ` [PATCH 4/6] NetLabel: rework the Netlink attribute handling (part 1) paul.moore
2006-09-21 16:57   ` paul.moore
2006-09-25  9:12   ` Thomas Graf
2006-09-21 16:57 ` [PATCH 5/6] NetLabel: rework the Netlink attribute handling (part 2) paul.moore
2006-09-21 16:57   ` paul.moore
2006-09-25  9:43   ` Thomas Graf
2006-09-25 14:13     ` Paul Moore
2006-09-25 14:13       ` Paul Moore
2006-09-25 15:06       ` Thomas Graf
2006-09-25 15:42         ` Paul Moore [this message]
2006-09-25 15:42           ` Paul Moore
2006-09-21 16:57 ` [PATCH 6/6] NetLabel: update docs with website information paul.moore
2006-09-21 16:57   ` 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=4517F8CB.1030707@hp.com \
    --to=paul.moore@hp.com \
    --cc=jmorris@redhat.com \
    --cc=netdev@vger.kernel.org \
    --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.