On 6/16/15 2:19 AM, Daniel Borkmann wrote:
if you really want to, you could go via skb->sk->sk_socket->file and then retrieve credentials from there for egress side (you can have a look at xt_owner). You'd need a different *_proto helper for tc in that case, which would then map to BPF_FUNC_get_current_uid_gid, etc. But that doesn't work for ingress however, even if you would have early demux, so you would need to let the eBPF helper function return an error code in that case.
was looking at cls_flow to do exactly that, but with different helper name. Like bpf_get_socket_uid_gid(). The use case is to collect network statistics per-user and per-process. I think android still using some out of tree hacks for that. Ingress indeed is not solved by this skb->sk->sk_socket approach. I considered kprobe style, but accessing skb->len via probe_read is kernel specific, nonportable and slow-ish. Ideally we would allow a blend of tracing and networking programs, then the best solution would be one or two stable tracepoints in networking stack where skb is visible and receiving/transmitting task is also visible, then skb->len and task->pid together would give nice foundation for accurate stats. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
