On Wednesday 2010-09-22 01:10, Eric Paris wrote: >>>My current patch looks like so: >>> >>>cat /proc/net/nfs_conntrack >>> >>>ipv4   2 udp   Â17 8 src=10.11.231.82 dst=10.11.255.156 >>>sport=34095 dport=53 src=10.11.255.156 dst=10.11.231.82 sport=53 >>>dport=34095 mark=0 secmark=system_u:object_r:unlabeled_t:s0 use=2 >> >> I think that rather than bloating ancient procfs files with more info, >> the respective userspace tool should be augmented by secmark name >> resolution instead. Then we would also not need change anything inside >> the kernel, or its interfaces to userspace. > >It is not possible for userspace to resolve these numbers to something >useful. They are dynamically generated numbers which are just kernel >internal helpers. Ok so I had a misconception about how `ls -Z` worked. Guess the UID/GID stuff misled pretty hard. > This is the only known place that the kernel shows >its underpants to in public and it should be fixed. My only question >is if fixing like this it is likely to break anything. > > Otherwise I'm >going to hard code those to 0 or 1 and export the label in a new >field.... The allocated secmark nlattr value should not be reused; it's easy to use a new nla id for the secname and omit transmission of secmark in nl chatter. For ye olde /proc/net/nf_conntrack, we can just remove secmark altogether because userspace does not depend on it. -- 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
