Hello.
Paul Moore wrote:
> Perhaps you could move the security_post_accept() hook further up and add a
> return value? I do not see any current in-tree users of the hook and I
> imagine moving it up would actually make the existing hook a bit more useful
> in general.
If there are no objections, that's a possible way.
> In the existing security_socket_recvmsg() hook you could peek at the top of
> the socket's receive queue and determine all of the information you would
> want to know to make your access decision. Granted, it still might be a bit
> racy if you have two threads reading from the same socket (maybe there is a
> lock there, I would have to check it further) but it can't be any worse then
> performing an access check _after_ the fact ...
I think dequeuing this message is needed, or programs that call recv() like
while (1) {
FD_SET(fd, &rfds);
select(fd + 1, &rfds, NULL, NULL, NULL);
recv(fd, buffer, sizeof(buffer), 0);
}
will begin meaningless infinite loop.
A proper way to avoid this loop will be "not to return ready answer for
select()".
But to do so, I will need modifications in lower layer where it is not allowed
to sleep.
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
