[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200904212039.JID59468.LOFOtMQOFJFSVH@I-love.SAKURA.ne.jp>
Date: Tue, 21 Apr 2009 20:39:08 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: davem@...emloft.net
Cc: paul.moore@...com, linux-security-module@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH] LSM: Add security_socket_post_accept() and security_socket_post_recv_datagram().
David Miller wrote:
> There is no sane way for the user to handle this connection
> being aborted, and there is no way to insert the connection
> back into the listening socket queue once we get to this
> point so we can't replay this situation either.
>
Excuse me, I couldn't catch.
I don't have a problem that there is no way to insert the connection back into
the listening socket queue once we get to this point. I want to drop the
connection rather than pushing the connection back to the queue.
I meant that "if we allow doing something after sock->ops->accept(), we need to
drop the connection if something returned an error". An example of something is
to assign/modify state. To modify task's state, I need to allocate memory for
new credential which is an operation that could fail.
Therefore, the socket_post_accept() hook should allow aborting the connection.
Paul doesn't like using the socket_post_accept() hook to abort connections.
But the connection is aborted if either newsock->ops->getname() or
move_addr_to_user() returned an error. I wonder what's so problematic with
using socket_post_accept() for dropping the connection.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists