From: Mr Dash Four <mr.dash.four@googlemail.com>
To: Eric Paris <eparis@parisplace.org>
Cc: netfilter@vger.kernel.org
Subject: Re: decipher the secmark number from nf_conntrack/ip_conntrack
Date: Tue, 21 Sep 2010 23:29:48 +0100 [thread overview]
Message-ID: <4C9931DC.8000800@googlemail.com> (raw)
In-Reply-To: <AANLkTiny3JCZnWOwHs9OY1vWqTsWAfxFqkiRW5RrRxX+@mail.gmail.com>
> No disagreement that Tom's patch is better than what we have today, I
> just claim that what we have today is completely wrong, so this is
> only slightly better :)
>
No argument there!
> sids, secids, secmarks, or whatever you want to call that u32 is just
> a dynamically generated number which should only exist inside the
> kernel and should never be shown to userspace. Loading secmark rules
> uses a full context string and then uses that string to generate a u32
> which the kernel can efficiently use. When we display things back to
> userspace we should always be converting that u32 back to a string.
> I'm working on a patch to do this (actually it's compiling while I
> type)
>
Again, we are in agreement - 100%
What baffles me really is how has this survived for so long?
The secmark field number has been there, I assume, for ages and yet
nobody could make sense of that number let alone, as you rightly pointed
out, raise the issue that this number should not be there in the first
place!
next prev parent reply other threads:[~2010-09-21 22:29 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-19 23:04 decipher the secmark number from nf_conntrack/ip_conntrack Mr Dash Four
2010-09-20 0:48 ` Jan Engelhardt
2010-09-20 10:41 ` Mr Dash Four
2010-09-20 12:23 ` Jan Engelhardt
2010-09-20 12:42 ` Mr Dash Four
2010-09-20 18:15 ` Mr Dash Four
2010-09-20 21:49 ` Tom Eastep
2010-09-20 23:26 ` Jan Engelhardt
2010-09-20 23:55 ` Tom Eastep
2010-09-21 9:59 ` Mr Dash Four
2010-09-21 20:13 ` Mr Dash Four
2010-09-21 20:26 ` Eric Paris
2010-09-21 21:00 ` Eric Paris
2010-09-21 22:38 ` Mr Dash Four
2010-09-21 22:42 ` Jan Engelhardt
2010-09-21 22:51 ` Mr Dash Four
2010-09-21 23:10 ` Eric Paris
2010-09-21 23:35 ` Jan Engelhardt
2010-09-23 18:39 ` Eric Paris
2010-09-23 18:49 ` Jan Engelhardt
2010-09-23 18:52 ` Eric Paris
2010-09-23 18:57 ` Jan Engelhardt
2010-09-23 18:58 ` Eric Paris
2010-09-23 19:20 ` Mr Dash Four
2010-09-23 19:51 ` Jan Engelhardt
2010-09-23 20:05 ` Mr Dash Four
2010-09-23 20:18 ` Mr Dash Four
2010-09-23 20:34 ` Eric Paris
2010-09-23 20:38 ` Mr Dash Four
2010-09-23 20:53 ` Jan Engelhardt
2010-09-23 20:56 ` Mr Dash Four
2010-09-23 21:23 ` Jan Engelhardt
2010-09-23 21:38 ` Mr Dash Four
2010-09-23 22:12 ` Jan Engelhardt
2010-09-23 22:30 ` Mr Dash Four
2010-09-23 22:42 ` Eric Paris
2010-09-23 23:59 ` Jan Engelhardt
2010-09-24 0:24 ` Tom Eastep
2010-09-24 0:32 ` Mr Dash Four
2010-09-24 1:18 ` Jan Engelhardt
2010-09-24 0:27 ` Mr Dash Four
2010-09-23 20:42 ` Jan Engelhardt
2010-09-23 20:53 ` Mr Dash Four
2010-09-21 22:29 ` Mr Dash Four [this message]
2010-09-22 2:25 ` Tom Eastep
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=4C9931DC.8000800@googlemail.com \
--to=mr.dash.four@googlemail.com \
--cc=eparis@parisplace.org \
--cc=netfilter@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox