Re: xt_AUDIT additions

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

> xt_owner did the same - it scanned the process table. According to 
> Christoph Hellwig, this was declared as some gross abuse, and, IIRC, the 
> reason was something like the tasklist lock was held "quite long" (which 
> makes sense).
Yep, it is the reason I was very reluctant to use this approach and seek 
to find another, more "efficient" way.

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

> But with xt_AUDIT, you would have to traverse the entire list, because 
> you would want to find all PIDs - since a socket may be shared between 
> multiple threads/processes - which in itself may generate a huge list 
> (=another problem) in the audit records.
>   
Isn't there a more efficient solution to this? The thought of scanning 
the task list to find ids for a single packet makes my head hurt!

> Also, the PID owner may not be the socket owner for the same reason.
>   
That's where auid comes in - it determines, unequivocally, the "root" 
process owner.

For example: if I log in as root and start a process, which then uses 
another id (say process squid using user id _squid), which spawns 
further processes under the same id, the "normal" uid (i.e. the 
information of the socket "owner") is probably going to show me uid = 
_squid, but the auid will show "root" as this is the "root" session 
which started all sub-processes and I suspect was one of the reasons 
auid was introduced in the first place - to remove this ambiguity.