Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > On Thu, Dec 08, 2016 at 10:32:00PM -0800, Cong Wang wrote: > >> > Why do we do autobind there, anyway, and why is it conditional on >> > SOCK_PASSCRED? Note that e.g. for SOCK_STREAM we can bloody well get >> > to sending stuff without autobind ever done - just use socketpair() >> > to create that sucker and we won't be going through the connect() >> > at all. >> >> In the case Dmitry reported, unix_dgram_sendmsg() calls unix_autobind(), >> not SOCK_STREAM. > > Yes, I've noticed. What I'm asking is what in there needs autobind triggered > on sendmsg and why doesn't the same need affect the SOCK_STREAM case? With respect to the conditionality on SOCK_PASSCRED those are the linux semantics. Semantically that is the way the code has behaved since 2.1.15 when support for passing credentials was added to the code. So I presume someone thought it was a good idea to have a name for a socket that is sending credentials to another socket. It certainly seems reasonable at first glance. With socketpair the only path that doesn't enforce this with SOCK_STREAM and SOCK_PASSCRED that is either an oversight or a don't care because we already know who is at the other end. I can imagine two possible fixes: 1) Declare that splice is non-sense in the presence of SOCK_PASSCRED. 2) Someone adds a preparation operation that can be called on af_unix sockets that will ensure the autobind happens before any problematic locks are taken. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
