Thread (18 messages) flat view 18 messages, 4 authors, 2011-05-06

Re: [RFC v3 02/10] Revert "lsm: Remove the socket_post_accept() hook"

From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: 2011-05-05 21:44:33
Also in: lkml, netfilter-devel

Paul Moore wrote:
On Tuesday, May 03, 2011 10:28:24 PM Tetsuo Handa wrote:
quoted
Paul Moore wrote:
quoted
On Tuesday, May 03, 2011 10:24:15 AM Samir Bellabes wrote:
quoted
snet needs to reintroduce this hook, as it was designed to be: a hook
for updating security informations on objects.
Looking at this and 5/10 again, it seems that you should be able to do
what you need with the sock_graft() hook.  Am I missing something?

My apologies if we've already discussed this approach previously ...
Second problem is that genlmsg_unicast() might return -EAGAIN because we
can't sleep inside write_lock_bh()/write_unlock_bh().
Ah yes, the real problem.  I forgot that snet relied on a user space tool.  I 
tend to agree with others who have suggested this is not the right approach, 
but I understand why you want the post_accept() hook; thanks for reminding me.
However, it sounds that Samir says genlmsg_unicast() failure is not fatal.

Samir Bellabes wrote:
using snet_do_send_event() means that system is sending data to
userspace. the system is not waiting for a verdict from userspace.

If error occurs, we actually loose the information data.
I may be able to write a solution which try to send the data again, but
we need a exit solution for this loop (a number of try ?).
If genlmsg_unicast() failure is not fatal, snet doesn't need the
socket_post_accept hook. Samir, is genlmsg_unicast() failure fatal for snet?
(Although, I'd like to ask for revival of the hook for TOMOYO anyway.)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help