|To:||James Morris <jmorris@xxxxxxxxxx>|
|Subject:||Re: [PATCH] linux 2.9.10-rc1: Fix oops in unix_dgram_sendmsg when using SELinux and SOCK_SEQPACKET|
|From:||Ross Kendall Axe <ross.axe@xxxxxxxxxxxxxxxx>|
|Date:||Thu, 18 Nov 2004 07:25:38 +0000|
|Cc:||netdev@xxxxxxxxxxx, Stephen Smalley <sds@xxxxxxxxxxxxxx>, lkml <linux-kernel@xxxxxxxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>|
|User-agent:||Mozilla Thunderbird 0.8 (X11/20040913)|
James Morris wrote:
On Thu, 18 Nov 2004, Ross Kendall Axe wrote:
The man page then goes on to say "the error ENOTCONN is returned when the socket was not actually connected". Admittedly, this is not what my patch does; it returns ENOTSUPP, as do SOCK_STREAM sockets.
I'm not sure if we should return any error at all if an address is supplied to sendto() on SOCK_SEQPACKET. We're only required to ignore it.
This was, after all, the point of the patch. Well, that and closing the security hole opened by my earlier patch :-)
I would say that ENOTSUPP all the time would be more sensible. However, my
choice of error codes was determined by the ones used by SOCK_STREAM.
SOCK_SEQPACKET and SOCK_STREAM should use the same error codes, I would say. Further, they should use the codes specified by POSIX.
IMHO, there never was an SELinux bug here. SELinux merely exposed an existing bug.
I got this oops when trying to kill a modified version of seqpacket-crash which keeps sending in a loop and uses sendto() and an address with SOCK_SEQPACKET.
I'm unable to reproduce that, or the bug you mention in your other message. Care to send us your code?
I think that af_unix.c needs a bit of cleaning up. All of the functions are named as being stream vs dgram, even when the issue is connectionless vs connection-oriented. For example, unix_connectionless_connect would make a lot more sense than unix_dgram_connect. sendmsg and recvmsg are the worst since they require a mixture of SOCK_STREAM and SOCK_DGRAM semantics. It would be nice to rewite unix_dgram_recvmsg and unix_stream_recvmsg as four helper functions dealing with the connectionless, connection-oriented, datagram and stream operations and then have 3 wrapper functions (one for each socket type) calling the appropriate helpers. This is all strictly IMHO, of course.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: Fw: [Bugme-new] [Bug 3765] New: Network link down, when writting to sata disk AND network in use, Surakshan Mendis|
|Next by Date:|
|Previous by Thread:|
|Next by Thread:|
|Indexes:||[Date] [Thread] [Top] [All Lists]|