I am merely suggesting a fix for what should have been released in
the first place by correcting the value of secmark to show the
proper context instead of a number which means absolutely nothing to
anyone.
Exactly. Since the number is useless to most people, the procfs file
practically never had the feature "display useful secmark". Which
means that changing it is a feature addition rather than a bugfix.
Actually, no! The last time I checked this field was named secmark, not
secnumber! By its very name, secmark should have been displaying ...
well ... the secmark of that particular connection!
Whoever designed that part of the interface (it wasn't you by any
chance, was it?) thought, wrongly, that secmark means
'show-me-the-internal-number-the-kernel-uses-to-identify-that-security-mark-for-that-particular-connection'!
That, as already Eric pointed out, was wrong - the kernel should never
show its underpants in userspace (very well-put, I have to say!). So, by
all definitions - this is a bug (and not an additional feature) and it
has to be corrected.
What I cannot understand is this - why are you so stuck up on this not
getting corrected - are you afraid that if the secmark field bug is
fixed your precious conntrack-utils won't have as much appeal?
--
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
