On Tue, Sep 21, 2010 at 7:35 PM, Jan Engelhardt <jengelh@xxxxxxxxxx> wrote: > > 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. How does one use the secmark netlink socket? How do I test my code? I'm sure this is an obvious question for most of you, but not for me :) -Eric -- 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
