In a way, it did display the secmark. :-)
Of course it doesn't. This is a number generated internally by the sel
engine (it is called sid). End users were never meant to see this number
- at all. selctx is the field which is designed for user space and for
'general' consumption.
Just like ipt_LOG prints
nfmark or IP addresses. The values may not mean much to the outside
world, but that's what we have DNS and selctx (James's original
naming) for.
Again, all of the above is meant to be in userspace, sid isn't.
If users would not
constantly insist on using outdated interfaces (and I _do_ grant
things their transition time),
Who are you to judge what consumers - both users and developers alike -
should or shouldn't use?
and if maintainers would not always
give in to these users, we would have less code to worry about, or
even have these discussions.
Yeah right, so if I need to see a secmark on a particular connection
instead of typing a simple 'cat /proc/net/nf_conntrack', or, as is in my
case use an existing tool (Shorewall) to check for such contexts, lets
just bloat my system with yet another set of useless tools, install
conntrack-utils and execute 'conntrack -L' for that privilege instead?!
You should be working for Microsoft!
I am not, for a moment, suggesting that netfilter tools should not be
able to map and get the context - what I am saying is that consumers
(both users and developers) should be given a choice to use both methods
- either via /proc (as is the case right now) as well as by other 3rd
party userspace tools - the choice is theirs to make.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
