Hello. Paul Moore wrote: > I apologize for not recognizing your approach from our earlier discussion on > the LSM mailing list in July. Unfortunately, I have the same objections to > these changes that I did back then and from what I can recall of the > discussion the rest of the kernel networking community agreed that these > changes are not the preferred way of solving this problem. We offered > suggestions on how to accomplish your goals in a way that would be acceptable > upstream and I would encourage you to investigate those options further.
When I proposed a patch in July, I was patching at post-copy_to_user() step (i.e. after sock_recvmsg()). This approach messed up user-supplied buffer. This time, I'm patching at pre-copy_to_user() step (i.e. at skb_recv_datagram()). This approach doesn't mess up user-supplied buffer. I think this is a cleaner way than the previous patch. Although read() gets an error when select() said "read ready", I can't find other place to use for accomplishing my goals. By the way, similar thing can happen when select() against a file descriptor said "read ready" but read() gets an error if security policy or security-id of the file has changed between select() and read(), isn't it? And such behavior is acceptable, isn't it? If such behavior can happen and is acceptable and *preferable*, I think checking permission at dequeue time (i.e. skb_recv_datagram()) is *preferable* way than checking permission at enqueue time (i.e. socket_sock_rcv_skb()). Regards. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
