However, xt_owner did not held the tasklist [write] lock, just
entered a RCU read section. hch: Was this RCU section also too long?
xt_owner had the bonus that it only had to check whether the socket
was owned by a particular user/group/pid/sid, which means it can stop
looping the tasklist as soon as it found a match.
I'll have a look at the xt_owner code later to see if there is
something I could use/learn.
Interesting, thanks for all the pointers!
xt_owner.c does have some answers.
skb->sk->sk_socket->file->f_cred->fsuid and
skb->sk->sk_socket->file->f_cred->fsgid seems to point to the socket
user id/group id owner. That, to my understanding, may not always be the
uid/gid responsible for sending a particular packet via this particular
socket, or have I got this wrong?
Moving on to the process id, I take it skb->sk->pid (or is it
skb->sk->sk_socket->sk->pid?) holds the pid list of the process(es)
owning the socket, right? Should I assume that the process responsible
for sending a particular packet could be found by traversing that list
or do I have to look elsewhere?
Also, am I right in assuming that only one process is responsible for
sending a particular packet? If that is the case, then there must only
be a single, unique triple of uid/pid/gid for each packet. If that is
so, how do I know which uid/pid/gid is responsible for that?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
