Re: xt_AUDIT additions

[Mr Dash Four <mr.dash.four@googlemail.com>]

>> 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?