While I was reviewing the rest of the kernel tree, I also found...
/cboss/p4/rwatson/trustedbsd/mac/sys/fs/fifofs/fifo_vnops.c:
error = sosend(wso, (struct sockaddr *)0, ap->a_uio, 0,
/cboss/p4/rwatson/trustedbsd/mac/sys/fs/portalfs/portal_vnops.c:
error = sosend(so, (struct sockaddr *) 0, &auio,
These also strike me as similarly incorrect and fixable. Of course,
fifofs and portalfs are both home to much evil, so...
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Wed, 2 Oct 2002, Robert Watson wrote:
>
> I was groping around through the socket code today looking for more places
> to sprinkle mandatory access control magic, and noticed that in most parts
> of the system call and protocol-independent socket implementation,
> sosend() is never invoked directly: instead, pru_sosend() is invoked, and
> protocols have the option of implementing pru_sosend() using the central
> sosend(), or providing their own optimized implementation. However, the
> exception to this appears to be in the nfsclient code, where sosend is
> invoked directly on the socket:
>
> bootp_subr.c-
> bootp_subr.c: error = sosend(so, (struct sockaddr *) &dst,
> bootp_subr.c- &auio, NULL, NULL, 0, td);
> bootp_subr.c- if (error != 0) {
>
> ...
>
> krpc_subr.c- }
> krpc_subr.c: error = sosend(so, (struct sockaddr *)sa, NULL, m,
> krpc_subr.c- NULL, 0, td);
> krpc_subr.c- if (error) {
>
> It strikes me that instead it should be calling:
>
> error = so->so_proto->pr_usrreqs->pru_sosend(...)
>
> So that protocols can implement sosend as they see fit. The NFS server
> code appears to do this fine. Is this interpretation correct?
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> [EMAIL PROTECTED] Network Associates Laboratories
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
